You move from a spreadsheet to a database when the spreadsheet has run out of room: when several people need to write at once, when it has grown so big it's slow or breaks, or when the formulas are no longer understood even by whoever wrote them. The jump happens in four moves: separate the things you talk about into tables (customers, orders, products), clean the data before importing it, put a screen in so no one touches the tables raw, and migrate in parallel for a few weeks until you trust the new system.
If your spreadsheet is small, one person uses it and it gives you no grief, change nothing. A database is more powerful and also more cumbersome. The rule isn't "a database is better", it's "a database pays off when the spreadsheet starts failing for what it is, not for how you're using it".
When does a spreadsheet run out of room?
When at least one of these three signs shows up. One is enough to consider it; with two, the jump almost always pays off.
- Several at once. Two people open the sheet and step on each other: one saves over what the other just typed. Up pop "copy of copy (2) FINAL_good.xlsx" and no one knows which is the real one. A spreadsheet is built for one owner; a database, for several who write without wrecking each other's work.
- Too big. The sheet goes past a few thousand rows, takes ages to open, hangs on recalculation, or one day corrupts and you lose half a morning. Spreadsheets hold hundreds or a few thousand lines well; not tens of thousands with formulas everywhere.
- Impossible formulas. You've got eight tabs linked with VLOOKUP, cells that depend on others that depend on others, and when something comes out wrong no one dares touch it for fear of breaking the rest. When the sheet has become a fragile program written in formulas, it was asking to be a real program.
If none of them show up, stay in the spreadsheet. The best database is the one you don't have to build.
What do you need to be clear on before you start?
Two things, and neither is installing anything.
The first is what things your sheet talks about. Look at it and note the nouns that repeat: customer, order, product, invoice. Each of those will be a table. Right now you probably have them all mixed in one sheet: in the same row sit the customer, the order and the product, and the customer's name appears a hundred times spelled three different ways. Modelling is separating that: a customers table (each customer once), an orders table, and a link between them.
The second is the relationship between those things: a customer has many orders, an order has many product lines. That "has many" is what a database does well and a spreadsheet does with great effort. You don't need the jargon; it's enough to sketch it on a napkin: boxes and arrows.
How do you do it, step by step?
Six steps, in this order:
- Confirm the spreadsheet has run out of room. Go over the three signs above. If none show up, don't go on: you save yourself the building work.
- Separate the things you talk about. The nouns that repeat (customers, orders, products) become tables. Each piece of data in one place only: the customer's phone lives in the customers table, not repeated in every order.
- Clean before importing. Unify date formats, remove duplicates, decide what you do with the gaps and the "pending / PDG / -". Importing junk into a database only gives you tidy junk, and then it costs more to get it out.
- Pick the database to fit the case. Airtable or Baserow (this one you can host yourself) if you want something visual, with tables and forms, no coding. PostgreSQL or SQLite with a small application on top if the volume is high or there are your own rules. The simplest that holds.
- Put a screen in front. No one should write straight into the tables. A simple form validates what comes in —that the email looks like an email, that the amount is a number— and stops someone wiping half the database in one go.
- Migrate in parallel. Sheet and database running side by side for a few weeks. You enter the data into both or check they give the same numbers. You only switch the sheet off when you trust the database. Never on day one.
The step people skip is the third, and it's the one that decides whether the project goes well. Everyone wants to import now and see the database full. But a database full of dirty data is worse than the spreadsheet: it looks serious and lies just the same.
Spreadsheet or database? When each one
It's not that one is better. They're for different moments:
| Spreadsheet | Database | |
|---|---|---|
| Who uses it | One person, or a few taking turns | Several at once without clashing |
| Comfortable size | Hundreds or a few thousand rows | Tens of thousands and up |
| Repeated data | The same customer written many times | Each piece once, linked |
| How you enter it | You type into the cell directly | Through a form that validates |
| Strong at | Starting fast, one-off calculations, prototypes | Growing, sharing, keeping order |
Plenty of businesses live for years on spreadsheets and do fine. The problem isn't using spreadsheets; it's carrying on with them when they're already creaking at every seam.
How much does it cost and how long does it take?
It depends where you come in. With a tool like Airtable or Baserow, someone handy sets up the tables and a couple of forms in a few days, and the cost is the monthly fee (or nothing if you host Baserow yourself). With a custom database —relational tables plus an application on top— it runs from a couple of weeks to a month depending on how many entities and rules there are, but then it's yours, with no fees and no third-party limits.
What you save isn't only time: it's no longer having three versions of the same data fighting each other, and no longer losing mornings when the sheet corrupts. One piece of data in one place is worth more than the same piece in five.
When is it NOT worth it?
- When the spreadsheet is small and one person's. If it works, gives no trouble and no one shares it, changing it is starting building work for the fun of it.
- When what you're missing is seeing, not storing. If your data is fine in the sheet but you can't draw conclusions from it, you don't need another database: you need a dashboard on top of the sheet itself. Changing systems won't give you the view you're after.
- When no one is going to maintain the screen. A database with no form in front ends up being a worse spreadsheet: people type raw, put in whatever they like, and in three months it's as dirty as it was. If no one will hold up the entry, don't make the jump yet.
What mistakes do people usually make?
Almost all come from treating the database like a spreadsheet with a new name.
- Copying the spreadsheet as is. Dumping the giant sheet into one enormous table isn't migrating; it's moving the problem to a new place. If you don't separate into tables, you've gained nothing.
- Importing without cleaning. The dates in four formats, the names with and without accents, the duplicates: if they go in like that, they stay like that, and now it costs more to fix them.
- Letting people in raw. With no form to validate, the database gets dirty on its own. Someone types "Madird", another puts the amount in words, and goodbye to the order that cost so much.
- Switching the spreadsheet off on day one. Trusting the database before you've checked it is the fastest way to lose data. Parallel for a few weeks, always.
Frequently asked questions
When does a spreadsheet run out of room?
When one of these three signs shows up: several people need to write at once and step on each other; the sheet has grown so big it's slow, crashes or corrupts; or the formulas and linked tabs have become impossible to understand and maintain. One sign is enough to consider it; with two, the jump usually pays off.
Which database should I choose to start?
If you want something like a spreadsheet but genuinely multi-user, Airtable or Baserow (which you can host yourself) give you tables, forms and permissions without coding. If the volume is high or there are your own business rules, a relational database like PostgreSQL or SQLite with a small application on top scales better. Start with the simplest that holds your case.
Will I lose my data when I migrate?
No, if you migrate in parallel. The key is not to switch the spreadsheet off on day one. You keep sheet and database running side by side for a few weeks, check they give the same numbers, and only when you trust the database do you stop using the sheet. The original spreadsheet is kept anyway as a frozen copy.
When is it NOT worth moving from a spreadsheet to a database?
When the spreadsheet is small, one person uses it and it gives no trouble: changing it is starting building work for nothing. And when what you're actually missing is seeing the data, not storing it better: there you need a dashboard on top of the spreadsheet, not a change of system.
The spreadsheet isn't the enemy; staying in it once it creaks is
You move to a database when the spreadsheet fails for what it is: several at once, too big, impossible formulas. Then you separate into tables what used to be piled up, clean the data before importing, put a screen in that validates the entry, and migrate in parallel until you can switch the sheet off with peace of mind.
If your spreadsheet is small and one person's, stay in it. And if what you're missing is seeing the data, not storing it better, yours is a dashboard, not a move. Change systems only when the system is the problem.
Is your spreadsheet already creaking?
If several of you are fighting over the same file, the sheet takes ages to open or no one understands the formulas any more, we can look at your case and tell you whether a tool like Airtable does the job or it calls for a custom database. If the spreadsheet is still serving you well, I'll tell you and we'll leave it alone. Tell me how you work with that data today.
See the custom software service Let's talk about your case