Almost every small organisation starts out with a spreadsheet. It makes sense: it opens in seconds, everyone knows how to use it, and no technician is needed. The trouble is that the spreadsheet grows along with the business and, at some point, stops being a tool and becomes a risk. Recognising when that shift happens lets you change course before a mistake becomes expensive.
What a spreadsheet does well
A spreadsheet is excellent for working with data in an exploratory way. You paste in some values, write a formula, build a chart and get an answer. It works very well for:
- quotes and simulations, where you change the parameters and watch the result;
- small lists managed by a single person;
- one-off analyses on a data export;
- prototypes, to understand which information is really needed before designing something more robust.
In all these cases flexibility is an advantage. Nobody imposes rules on what goes into a cell, and that makes the work fast.
Where the problems begin
That same flexibility becomes a flaw when data must stay correct over time and must be shared. A relational database exists precisely to enforce rules a spreadsheet knows nothing about.
No constraints on values
In a «Delivery date» column one person will type 03/04/2025, another 2025-04-03, a third «early April». The spreadsheet accepts all of them. A database with a DATE column rejects the invalid value the moment it is entered, which is when fixing it costs least.
Duplicated and inconsistent data
If a customer's address is repeated across fifty order rows, changing it means updating fifty cells. Forget one and you have two versions of the truth. In a database the address lives in a single customers table and orders refer to it through a key: you change it in one place and the data is consistent everywhere.
Concurrent access
Two people editing the same file at the same time create conflicts, «final_v2_definitive» copies and overwrites. Cloud tools have improved things, but they do not offer transactions: there is no way to say «record the order and reduce the stock, or do nothing at all». A database guarantees that both operations happen together or not at all.
Permissions that are too coarse
A file can usually be either read or edited in full. A database lets you allow a colleague to enter orders without being able to see salaries or delete customers.
Performance and size
When rows reach the hundreds of thousands, spreadsheets slow down, lookup formulas get heavy and opening the file takes minutes. A database with the right indexes answers in milliseconds even across millions of rows.
Concrete signs to help you decide
In my work I use a simple checklist. If at least three of these statements are true, moving to a database deserves serious consideration:
- more than two people regularly edit the same data;
- some information is repeated across several sheets or rows;
- at least one error has already occurred because of overwritten or inconsistent data;
- different people need different levels of access;
- the file has grown to a size that makes daily use slow;
- someone spends hours every month «fixing» the data before it can be used;
- other software needs to read or write that data automatically.
Intermediate alternatives
You do not always have to jump straight to a database server with a custom application. There are intermediate steps:
| Solution | Suitable when | Main limitation |
|---|---|---|
| Spreadsheet with data validation and separate sheets per entity | Few users, simple rules | Constraints can still be bypassed |
| No-code tools based on linked tables | Small teams, data-entry forms | Vendor dependency, per-user costs |
| Desktop database or SQLite with a simple interface | One user or limited access | Limited concurrency |
| Database server (PostgreSQL, MySQL, SQL Server) | Multiple users, integrations, growth | Requires design and maintenance |
How to approach the migration
The switch is not only technical: it is a chance to understand what data you actually manage.
- Column inventory. For each column, decide what it represents, what type it is and whether it is mandatory.
- Identify the entities. Customers, products, orders, suppliers: whatever is mixed together in the spreadsheet should be split into separate tables.
- Clean up first. Dates in different formats, stray spaces and names spelled in different ways should be standardised before the import, not after.
- Trial import. Load a copy, compare totals and counts with the original spreadsheet and note any differences.
- A short overlap period. For a few days you can keep the spreadsheet read-only as a reference, but with a firm end date: two parallel systems running for months create exactly the inconsistency you set out to remove.
The spreadsheet does not disappear: it remains the ideal tool for analysing an extract from the database, running a simulation or preparing a chart. Its role changes, from archive to working tool.
In short
- A spreadsheet is perfect for exploring, simulating and prototyping.
- Its limits appear with multiple users, repeated data and the need for consistency.
- A database enforces types, constraints, transactions and permissions that protect the data.
- Intermediate solutions exist, to be chosen by number of users and integrations.
- A migration should be prepared with an inventory, a clean-up and a check of totals.
