When a spreadsheet stops being enough

Nobody plans this. Someone makes a sheet to track one thing, it works, and two years later it runs a business. The sheet didn't fail — it succeeded so hard it turned into something else. The question isn't whether spreadsheets are good (they are). It's whether this file is still a spreadsheet, or a database doing an impression of one.

Here are the five signals, in the order they usually appear.

1 · The tabs are secretly tables

Look at the tab strip. If it reads Bookings, Guests, Rooms, Prices, you're looking at a schema — four kinds of thing, each with its own columns, related to each other by names retyped across tabs. If it reads Jan, Feb, Mar, you're looking at one table cut into twelve pieces, and every "how did the year go" question now requires stitching them back together.

Either way, the tabs stopped being worksheets a while ago. They're tables without any of the machinery tables come with. There's a longer version of this in tables, not tabs.

2 · VLOOKUP is load-bearing

One VLOOKUP is a convenience. A chain of them — bookings looking up guests, guests looking up companies, a helper column feeding another helper column — is a set of relationships, expressed in the one notation that breaks when somebody inserts a column. The match key is usually a name typed by hand, so "Acme Ltd" finds the company and "Acme Ltd." finds #N/A, and the person who understands why is signal four.

In a database this entire layer doesn't exist. A record links to another record, and the link survives renames, sorts and inserted columns because it was never a formula matching strings.

3 · Copy-paste is the sync engine

The sales sheet needs the client list, so the client list is pasted in, monthly, by hand. Or exported from one file and imported into another. The moment the same fact lives in two files, one of them is wrong — you don't know which, and you find out at the worst available moment.

Copy-paste sync is the clearest signal of the five, because it means the sheet has acquired consumers. Other people, other files, sometimes other software, all want its contents. That's what an API is for — readers pull the current truth instead of a paste of last month's.

4 · Only one person can touch it

Every long-lived sheet grows a keeper: the one who knows that column Q feeds the pivot, that you must never sort by column C, that the March numbers are wrong but corrected further down. When the keeper is on holiday, work queues behind them. When they leave, the file becomes read-only by fear.

This isn't a character flaw of theirs. The sheet's rules genuinely aren't written anywhere — they can't be, because a spreadsheet has no place to put "this column is a date" or "this value must be one of these five". A database holds those rules as structure, which is precisely what makes it survivable when a new person opens it cold.

5 · The sort that broke a row

The scar every veteran sheet carries. Someone selected a column — not the whole sheet — and sorted. Names moved; the amounts stayed. Every row is now a name attached to someone else's numbers, the damage is invisible, and undo expired days before anyone noticed.

That this is possible is the deep difference. A spreadsheet is a grid of independent cells that mean whatever their position implies. A database row is one record — sort a table all day and a booking can never end up with another guest's dates.

What actually changes on the other side

Four things, and they're exactly the four the signals point at:

• Types. A date field holds dates. "next Tuesday" is refused at the door, not discovered in a report.
• Relationships. A booking links to its guest. One guest record, no matter how many bookings — explained properly here.
• Views. Filtered, sorted, grouped arrangements of one table, saved side by side. Nobody duplicates a tab to get a different angle, so nothing drifts.
• An API. Whatever consumed your pastes reads live records instead.

What you lose — honestly

The move costs real things, and pretending otherwise is how people end up resenting the tool.

Free-form layout. In a sheet, anything can go anywhere: a note in the margin, a total under the table, a second little table floating to the right. A database has none of that. Every value belongs to a field on a record, or it has no place to exist. Structure is the feature, and it is also the restriction.

Formulas anywhere. Spreadsheet formulas live per cell — scratch math in E14, a quick sum under a column. Database formulas are per field: one expression, computed for every record. For per-thing arithmetic that's an upgrade (see formula, lookup or rollup). For modeling and what-ifs, it's not the tool — which is why the usual arrangement is both: structured records in the database, exported into a sheet when it's time to think.

Zero-setup starts. A blank sheet asks nothing. A database asks you to decide what your tables are before the first record lands. It's an afternoon's honest work, and most of it is reading your own sheet critically.

If you're seeing none of the five signals, keep the sheet. It's the right tool for one person's flexible thinking, and moving would buy you structure you don't yet need.

If this is your sheet

Two or three signals is the threshold — that's when the sheet is doing a database's job without a database's guarantees, and the category to look at is a no-code database: the structure without the SQL.

Tabla is ours. Importing a spreadsheet reads CSV or Excel, shows you every type it guessed before creating anything, and the whole database comes back out as one file any day you want it to — so trying it doesn't cost you the sheet.