What a database is and why your spreadsheet is becoming one
A spreadsheet several people edit, with rules nobody dares change, is a database without the safety. What a database adds, and when to switch.
The short answer
A database is a system built to store records safely: each record has defined fields, rules about what is allowed in them, and a history of who changed what. Many people can read and write at the same time without overwriting each other, and other systems can read the data through an interface. A spreadsheet is a grid of cells with formulas. It is superb for one person’s analysis and it becomes dangerous the moment it is the system a business runs on.
Most custom software we build replaces a spreadsheet that crossed that line years ago.
What a database adds
| Need | Spreadsheet | Database with a small application |
|---|---|---|
| Several people editing at once | Conflicts, overwrites, “who changed this” | Safe concurrent access, every change attributed |
| Only valid values entered | A date typed as text; an amount with a stray letter | Validation: the wrong kind of value is refused |
| Relationships between things | Copying the customer name into every row | One customer record, referenced by every order |
| History | None, or a copy named final_v3 | Who changed what, when, and what it was before |
| Other systems reading the data | Export and email | An interface they can call directly |
| Permissions | Everyone sees everything | Each role sees and edits what it should |
| Backups | Whatever the file share does | Automatic, tested, restorable to a point in time |
The signs your spreadsheet has become a system
- Several people edit it. And there have been arguments about who broke it.
- There is a cell that says “do not edit”. Someone learned the hard way.
- There are tabs per month or per year. The data outgrew one sheet and the structure followed.
- Copies travel by email. Nobody knows which one is current.
- One person understands the formulas. Their holiday is a business risk.
- It is referenced in every meeting. It is the system of record, whatever the organisation chart says.
Switching without a big bang
The spreadsheet is not the problem; it is the specification. Its columns are the fields, its tabs are the record types, its formulas are the rules, and the workarounds people built around it are the requirements nobody wrote down. A small application on a managed database, with the screens people actually use, is usually a matter of weeks. The data is cleaned and imported once, the spreadsheet becomes read-only history, and the arguments about who broke it stop.
What this means for you
If a spreadsheet meets three or more of the six signs, the business is running on a system without safety, history or permissions. Treat the sheet as the specification, scope a small application on a managed database that does what the sheet does with the rules enforced, and import the data once. It is the most reliable return on custom software we know, because the requirements are already in the cells.
Frequently asked questions
Is a database complicated to have?
Not anymore. Managed databases are a service you rent, backed up and maintained by the provider. What you build on top is a small application with the screens people need. The database itself is the least visible and least troublesome part.
Can we not just protect the spreadsheet better?
You can lock cells and restrict sharing, and it helps for a while. It does not give you multiple safe editors, validation of what is entered, a history of changes, or a way for other systems to read the data. Those are the things the business starts needing, and they are what a database provides by design.
What happens to the existing spreadsheet data?
It is imported once, after cleaning, which usually reveals duplicates and inconsistencies that were invisible in the sheet. The import is part of the project, and the spreadsheet becomes read-only history.