The Spreadsheet That Started Simple and Became a Problem
The business spreadsheet starts as a reasonable solution: a list of customers, a product inventory, a project tracker. It grows as the business grows — more rows, more columns, more sheets — until the file is tens of thousands of rows, multiple sheets are linked with complex VLOOKUP formulas, multiple people need simultaneous access, and the file takes 30 seconds to open. At some point, the spreadsheet stopped being the right tool for the job without anyone making a conscious decision to keep using it.
The signals that data has outgrown a spreadsheet are consistent and recognisable: multiple people can’t edit simultaneously without conflicts, the file is slow and crashes occasionally, queries that should be simple require complex formula gymnastics, the same information is stored in multiple places with the risk of inconsistency, and adding new data types or relationships requires restructuring that breaks existing formulas. These signals indicate that the data has database-shaped characteristics that spreadsheet structure isn’t designed to handle.
What a Database Provides That a Spreadsheet Doesn’t
A relational database (MySQL, PostgreSQL, SQLite, Microsoft SQL Server) stores data in tables with explicit relationships between them — the orders table has a customer_id column that references the customers table, allowing every order to be linked to a customer without duplicating customer information in every order row. This relational structure eliminates the data duplication and synchronisation problems that spreadsheets create when relationships are managed manually across multiple sheets.
Concurrent access without conflicts: databases handle multiple simultaneous users reading and writing data through transaction management that ensures consistency — two users updating the same record simultaneously produces a definite outcome (one update wins, the other sees the conflict) rather than the undefined overwrite that Excel shared editing produces. Performance at scale: a well-indexed database table with 10 million rows queries faster than a spreadsheet with 10,000 rows because database engines are designed for exactly this purpose.
The Middle Path: Low-Code Database Options
For organisations without database expertise, the middle path between spreadsheets and traditional databases has improved significantly: Airtable, Notion databases, and Microsoft Lists provide database-like structure (multiple linked tables, defined field types, relationship management) in interfaces familiar to spreadsheet users, without requiring SQL knowledge or database administration expertise.
Airtable in particular fills the gap between spreadsheet and database with a design that’s accessible to non-technical users: its interface resembles a spreadsheet, it supports multiple linked tables with relationship fields, it provides form views for data entry, and it offers basic automation. The limitation is that Airtable’s scalability is more limited than a real database and its pricing at scale is significant. For growing businesses that need relational data structure but don’t yet need or have the resources for a real database, Airtable is an appropriate intermediate step.
When to Actually Use a Real Database
The scenarios that specifically require a real database rather than a Airtable-style tool: large data volumes (hundreds of thousands to millions of records), complex querying requirements (multi-table joins, aggregations, analytical queries), integration with other systems via API, custom applications being built on top of the data, or compliance requirements that mandate specific database technologies and configurations.
The migration from spreadsheet to database is a project rather than a quick switch: data needs to be cleaned (enforcing consistent formats and removing duplicates), a schema needs to be designed (defining the tables, relationships, and data types), the data needs to be imported into the new structure, and the workflows that previously used the spreadsheet need to be updated to use the new system. For organisations at the scale where this project is warranted, the investment in a proper database migration pays back through improved reliability, performance, and capability within months.
The Transition Decision Framework
The questions that determine when a database transition is warranted: Is data entered and accessed by multiple people simultaneously? (If yes, spreadsheet concurrent access limitations are an active problem.) Is data growing to thousands of rows and the file becoming slow? (Database performance characteristics become relevant.) Do relationships between data types (customers, orders, products) need to be maintained consistently? (Relational database structure addresses this directly.) Are other systems or applications needing to read or write the data programmatically? (Databases provide API access that spreadsheets don’t.)
The practical starting point that produces the most useful information before committing to a transition: spend one week tracking every time the spreadsheet creates friction (errors from simultaneous editing, performance lag, formula errors when data is added or changed, time spent on manual consistency checks). The frequency of these incidents is the most reliable predictor of whether a database transition’s cost and effort will pay off.
