When a Spreadsheet Should Become a Database

There is a spreadsheet in your organisation that stopped being a spreadsheet some time ago. It has conditional formatting nobody remembers setting up, a hidden tab that everything else depends on, and a column of identifiers that is really a foreign key pretending not to be one.

It works. That is the awkward part. Nobody replaces a thing that works, right up until the morning two people edit it at once and a week of numbers goes missing.

The three signals that it has outgrown the grid

You do not need a framework for this. You need to check whether any of these is true.

• There are relationships in it. A cell holds a customer ID, a project code, an order number — something that means a row in another sheet. Keeping those two in step is now manual work, and manual work drifts.
• More than one person edits it. Not opens it. Edits it. The moment somebody keeps a private copy "just in case", you have lost the single version of the truth that made the sheet worth having.
• A formula has become a program. Four levels of nested conditionals, a lookup inside a lookup, and a comment that says do not change this. That logic belongs somewhere it can be named and tested.

One signal is enough. All three and you are not deciding whether to move, you are deciding how much longer to put it off.

What the four options actually cost

Published rates at the time of writing. Per-seat prices are the ones that surprise people, because everyone counts editors and forgets the six colleagues who only need to look.

Tool	Free tier	Paid from	Suits
Airtable	1,000 records per base, 1GB attachments	$20/user/month billed annually	Teams who want it to look finished
Notion	Unlimited pages, 5MB uploads, 7-day history	$10/seat monthly, $8 annually	Data that lives beside documents
Baserow	3,000 rows per workspace	$12/user monthly, $10 annually	Anyone who wants the option to self-host
NocoDB	Self-hosted, no row cap of its own	Free on your own hardware	Teams who already run Postgres

Airtable's Team plan lifts you to 50,000 records per base and 20GB of attachments, with a year of revision history; Business is $45 a user annually with 125,000 records. Baserow's paid tiers step through 50,000 and 250,000 rows per workspace. Notion counts differently — seats, file size and history depth rather than rows — which is a hint about what it is really for.

The distinction that decides it

Two of these tools are databases with a friendly grid on top. Two are something else.

Airtable and Baserow are the databases. Records, typed fields, links between tables, views that filter and group. If your problem is structure — the same shape of thing, many times, with relationships — this is the shape of the answer.

Notion is a documents product that grew tables. That sounds like faint praise and is not meant as it: when the table needs context around it, when each row wants a page of notes behind it, Notion is the only one of the four that does not feel like two tools stapled together. It is a poor choice for ten thousand rows of structured data and an excellent one for forty projects that each need a brief.

NocoDB is the odd one out and the most interesting for anyone technical. It does not want to own your data; it puts a grid over a database you already run, Postgres or SQLite included. The table stays queryable by your own application, which means the no-code layer is a view rather than a silo. If you already have a database and a person who is comfortable with it, that changes the calculation — as does knowing what your database can already do on its own, which we covered in our notes on the Postgres tools we reach for.

What you lose by leaving the sheet

Comparison articles skip this part, so here it is plainly.

You lose fast, unstructured arithmetic. In a spreadsheet you can put a number in an empty cell, sum a range beside it, and delete the lot ten minutes later. In a database tool that is a schema change, and schema changes have ceremony. For genuine modelling — a forecast, a scenario, a one-off calculation — a spreadsheet remains the better instrument, and moving that work into a records tool makes it slower for no benefit.

So the honest recommendation is often both: the structured data moves, the modelling stays in the sheet and reads from an export.

How to move without breaking the week

1. Count your rows and double it. That number, not the feature list, decides which free tier survives contact with next year.
2. Clean the sheet before you import. One header row, no merged cells, one type per column. Every minute here saves five later.
3. Move one table, not the system. Pick the table other things depend on, get it right, and leave the rest where it is for a fortnight.
4. Give people a view, not the grid. A filtered view or a form is what most colleagues need, and it prevents the accidental edits that made you leave the spreadsheet in the first place.
5. Point the automations at the new home. If a script or a scheduled job reads the old sheet, it is now reading a stale copy — and that failure is silent. Our guide to automating repetitive work without code covers where those jobs usually hide.

What we would do

For most small teams, Airtable if the budget allows and the team is small enough that per-seat pricing stays sane, Notion if the rows need paragraphs attached, and Baserow or NocoDB if you already run infrastructure and would rather own the data than rent it.

And if none of the three signals is true for your sheet, do nothing. A working spreadsheet that one person maintains is not technical debt. It is a spreadsheet, and it is allowed to stay one.