Google Sheets as a Database: A Free Setup and Where It Stops

Yes, you can use Google Sheets as a database for a small team, as long as you treat the file like one: one table per tab, one row per record, a unique ID in the first column, dropdowns instead of free typing, and a Google Form as the front door for new entries. Built that way, a free sheet runs an inventory spreadsheet, a simple CRM or a job-request log. It stops working when people need to see only their own rows, work mostly from a phone, or get roles that a shared file cannot enforce.

The rules that turn a sheet into a database

A database differs from a spreadsheet in discipline, not software. Each tab holds one kind of thing: items, locations, contacts, deals. Each row is one record. Each column is one field with one type of value, so a date column holds only dates. No merged cells, no blank rows, no totals inside the table. Records point to each other by ID instead of by retyped names. Reports and charts live on their own tab and only read from the data.

Most spreadsheet trouble starts with breaking one of those rules. Someone types Acme Inc. in one row and ACME in the next, and the totals split. Someone sorts a single column, and every row behind it falls out of line. Someone adds a subtotal row in the middle, and every formula below it now counts it twice. The fixes are boring. They also work for nearly every one of the small internal tools a team runs on spreadsheets.

The same rules in an Excel database

The rules hold in Excel too. Microsoft's route is to turn the block into a table: select a cell in your data, choose Home, then Format as Table, pick a style, confirm the cell range, tick the box if your table has headers, and select OK. The rest of this guide uses Google Sheets, because the form and sharing steps below are Google's own. If your team already works in Excel, keep the same one-table-per-sheet structure.

How to create a database in Google Sheets, step by step

Plan the tabs on paper first. It takes ten minutes. Write down the things you track and the facts you need about each one. For an inventory that might be Items, Locations and Movements; for a CRM, Contacts, Companies and Deals. Add one more tab called Lists to hold the allowed values for every dropdown. Then build it.

1. Create one tab per table, plus the Lists tab. Name each tab in the singular or plural, but be consistent.
2. Put field names in row 1 and nothing above them. One field per column, no merged headers.
3. Make column A the ID. Use a short code with a prefix, such as INV-0001 or DEAL-0001, and never reuse one.
4. Add dropdowns. Select the cells, click Data, then Data validation, then Add rule. Under Criteria, choose Dropdown from a range and point it at the right column on the Lists tab. Entries that don't match the list are rejected; to allow them with a warning instead, open Advanced options and set the invalid-data choice to Show a warning ^[1].
5. Pick one format per column for dates, money and phone numbers, and apply it to the whole column before anyone types.
6. Point other tabs at IDs. A Movements row stores the item's ID, not its name; lookups fetch the name when you need it.

Keep the rejection setting on for status and category columns. A warning lets typos through, and typos are what make a database count wrong.

Add a Google Form as the front door

Typing straight into the grid is where most rows break. A form gives each person the fields and nothing else, so nobody can sort a column, paste over a formula or delete a neighbor's record. In Google Forms, open the form, click Responses, then Summary, then More, and choose Select destination for responses. Pick Create a new spreadsheet or Select existing spreadsheet, then click Create or Select ^[2].

Google puts the responses into a table in that sheet. Two details from the same help page matter for a database. Form collaborators get access to a newly created response spreadsheet automatically. Later permission changes on the form do not carry over, so you update access on the form and the sheet separately. Treat the response tab as the inbox. Copy or reference its rows into your clean tables with formulas, and leave the raw responses untouched.

Protected ranges and filter views: who can change what

Protection keeps honest people from mistakes. That is all. In the sheet, click Data, then Protect sheets and ranges, then Add a sheet or range. Choose Range or Sheet, click Set permissions, and either show a warning on every edit or restrict who can edit: only you, only your domain (for work or school accounts where the whole domain can edit), or a custom list. Protect the ID column, the Lists tab and every formula column.

Google is blunt about the limit. Protection should not be used as a security measure, and people can still copy, print, export and import copies of a protected spreadsheet ^[3]. Hidden sheets are no better: editors can unhide them, and viewers can still reach their content through a copy.

Filter views solve a different problem. Click Data, then Create filter view, sort and filter, then Save View. Each person can use a different filter view at the same time without changing what others see, and you can share one as a link. Only one filter view applies at a time. Someone with view-only access gets a temporary filter view that isn't saved.

Example: an inventory spreadsheet and a CRM in Google Sheets

Here is an illustration with invented round numbers. The Items tab lists INV-0001, packing tape. The Movements tab logs every change as its own row: 120 received, then 30 issued, then 15 issued. Nobody edits a stock count by hand. A Stock tab computes it from the log:

=SUMIFS(Movements!D:D, Movements!B:B, A2, Movements!C:C, "In") - SUMIFS(Movements!D:D, Movements!B:B, A2, Movements!C:C, "Out")

The result is 120 minus 45, so 75 on hand. A log beats an overwritten count because you can always see why the number is what it is.

A CRM in Google Sheets follows the same pattern. Contacts and Companies hold people and firms. Deals holds one row per opportunity, with a Stage dropdown (Lead, Qualified, Proposal, Won, Lost), an owner and a next-step date. Each rep saves a filter view called My deals. That works well for a solo seller or a small team that trusts each other. Notice what it does not do: every rep can still open every deal.

Where Google Sheets as a database stops working

The free setup has a clear edge, and you usually hit it in one of five places.

• Per-person views. Anyone who can open the file can see every row. A filter view hides rows from the screen, not from the person. When a field tech should see only their jobs, or a client only their orders, the file cannot enforce it.
• Phone use. A wide sheet on a phone means sideways scrolling and tiny cells. Crews in a warehouse or on a job site need a screen built for one record at a time.
• Roles. Sheets knows owner, editor, commenter and viewer, plus protected ranges. It has no idea that a manager approves and a technician submits.
• Edits that collide. With many editors, one bad sort or paste can scramble rows that others depend on.
• Size and speed. Google caps a file at 20 million cells or 100 MB ^[4]. Heavy formulas across a large file get slow well before that.

The next step does not mean leaving the sheet. Several app builders put an app on top of the same data. Softr connects a Google Sheet as a live, two-way data source, and its own guidance says Google Sheets filters are not security, which is the same warning Google gives about protected ranges. It answers the first item on the list above: the field tech or the client sees only the records meant for them.

Glide Classic syncs two ways with one Google spreadsheet per app, so the Movements log from the inventory example stays the place where stock changes are recorded, whoever enters them. Watch which Glide you sign up for: GlideOS copies a connected sheet into its own table and does not write back, so the sheet stops being the source.

Base44 offers a Google Sheets connector as well, but it fits only part of this job. Its file imports suit a one-time move better than a sheet the team keeps editing every day.

These tools work differently once the data leaves the grid. Our guide to turning a spreadsheet into an app lays the routes side by side, from live sync to one-time import.

When the sheet needs an app on top

A shared sheet behaves like a database only under a database's discipline: one table per tab, IDs, dropdowns, a form for entry and protection on the columns that matter. That is enough for an inventory log, a small CRM or a request tracker that a trusted team shares. The moment people need their own view, a phone screen or real permissions, keep the sheet and put an app on top of it. Do not keep adding tabs and hoping.