Laravel News has covered a package that does something both useful and faintly alarming: it lets a Google Sheet act as a Laravel database connection.
The package, amazingbv/laravel-google-sheets-database-driver, registers Google Sheets as a database driver so Eloquent, the query builder and migrations can read and write directly to a spreadsheet. The model is intentionally simple. The spreadsheet is the database. Each tab is a table. The header row defines the columns.
That is not a replacement for MySQL, PostgreSQL or SQLite, and the package author is clear about the intended use case. This is for modest data needs: prototypes, small back-office applications, internal tools, light integrations, event RSVPs, editorial trackers or client-maintained lists where a full relational database may be more process than the job needs.
The setup follows the expected Google path. Create or choose a Google Cloud project, enable the Google Sheets API, create a service account, download the JSON key, point Laravel at the spreadsheet ID and credentials file, then give the service account editor access to the sheet. A package install command prepares internal tabs used by the driver.
From there, the Laravel side looks deliberately normal. You can run migrations against the google-sheets connection, define a model, and use familiar create/query operations. Writes appear in the sheet, so a non-developer can sort, filter or edit the same data surface the app is using.
The catch is that Google Sheets remains Google Sheets. There are no real foreign keys, database-level constraints or high-throughput writes. Laravel calls that imply constraints or transaction semantics may be accepted for compatibility, but the sheet will not enforce them. Use this where human-editable convenience is the feature, not where data integrity is the product.