Use a Google Sheet as Your Laravel Database with the Google Sheets Database Driver

The Laravel Google Sheets Database Driver by AmazingBV registers a custom google-sheets connection, letting Eloquent, the query builder, and migrations read and write directly to a Google Sheet.

The mental model is simple: the spreadsheet is the database, each tab is a table, and the header row defines the columns. The rest is plumbing the package handles for you.

#When this makes sense

This is not a MySQL replacement, and the package's author is upfront about that. The intended audience is teams with modest data needs: small back-office apps, prototypes, internal tools, and the kind of light integrations where reaching for MySQL or PostgreSQL feels like overkill. The clearest sign that this package is a fit is when the spreadsheet itself is already part of how the team works, non-developers want to look at or edit the data directly, the row counts stay modest, and you don't need the database to enforce relational rules for you.

If you need transactions, foreign keys, database-level constraints, or high write throughput, this is not the right pick.

#Getting set up

After installing with Composer:

composer require amazingbv/laravel-google-sheets-database-driver

You'll need a service account JSON key from Google Cloud. The short version: create or pick a Google Cloud project, enable the Google Sheets API, create a service account, and download its JSON key. The package's GitHub repo walks through these steps in more detail.

With the key in hand, point Laravel at your spreadsheet ID and the credentials file in your .env:

DB_CONNECTION=google-sheets
DB_DATABASE=your-google-spreadsheet-id
GOOGLE_SHEETS_CREDENTIALS_PATH=/absolute/path/to/service-account.json

The service account's client_email (from the JSON key) needs Editor access to the spreadsheet. Then a one-time install command prepares the internal tabs the driver uses:

php artisan sheets:install

#A small example

Imagine a tiny app for tracking RSVPs to a community meetup. The migration looks like a normal Laravel migration:

Schema::connection('google-sheets')->create('rsvps', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->string('email');
    $table->boolean('attending')->default(true);
    $table->timestamps();
});

Run it with php artisan migrate --database=google-sheets and an rsvps tab appears in the spreadsheet, headers and all.

The model itself doesn't require anything unusual:

class Rsvp extends Model
{
    protected $connection = 'google-sheets';
    protected $guarded = [];
    protected $casts = ['attending' => 'boolean'];
}

From there, the usual calls just work:

Rsvp::create([
    'name' => 'Ada Lovelace',
    'email' => 'ada@example.com',
    'attending' => true,
]);
 
$confirmed = Rsvp::where('attending', true)
    ->orderBy('created_at')
    ->get();

Every write shows up in the sheet immediately, which is the whole point: the event organizer can sort, filter, and tweak the data in Google Sheets while the Laravel app keeps reading the same rows.

#What you can and can't query

The driver supports a working subset of the query API rather than full SQL. You get where, whereIn, whereNull, whereLike, orderBy, limit, offset, the usual aggregates (count, sum, avg, and friends), and a simple in-memory inner join.

What you don't get: raw SQL, groupBy, having, unions, and real transactions. Laravel's DB::transaction() calls are accepted as no-ops, which keeps queue workers and framework internals happy but offers no rollback.

Migrations follow the same forgiving approach. Calls like ->unique(), ->index(), and ->foreignId()->constrained() don't fail, but Google Sheets won't enforce them either. If you depend on those guarantees, enforce them in application code.

#Living with API quotas

Google Sheets has tight per-minute API quotas, so the driver puts a few guardrails in place: in-process read caching, configurable per-minute throttles, exponential-backoff retries on quota errors, and an optional Laravel cache store (file, redis, etc.) for further reduction in API calls. All of those knobs are tunable from .env, and the author includes a short troubleshooting list for when you start seeing quota errors.

#The "Database Index" tab

One small detail worth calling out: the package keeps a visible Database Index tab as the first tab in the spreadsheet, with linked rows pointing at each table tab. It is a nice quality-of-life feature for anyone opening the sheet directly, and it makes the spreadsheet feel less like a black box and more like something a non-developer can navigate.

#Try it out

To learn more and view the source code, head over to the package's GitHub repository.