Yes, Excel may work as a database — for one person, with a few thousand rows, when nobody, not even the user, needs to know who changed what. That covers a lot of real work. It stops working at a predictable point: the moment more than one person has to update it. Here's exactly what Excel does well as a database, where it breaks, what people usually replace it with, and a way to get the database without giving up Excel.
What Excel does well as a database
A properly built Excel table is a competent flat-file database. Format the range as a Table and you get structured references, automatic expansion, per-column filters and sorting. Add XLOOKUP or INDEX/MATCH for lookups, a pivot table for aggregation, data validation for controlled inputs, and you have a system that a single owner can run for years. Every small company has a customer list, a vendor list, an asset register or an order log built exactly this way — and for a single owner they work.
Where it breaks
1. More than one editor, consumer or reader. The first time two people need to update the same list, Excel has no good answer. Co-authoring makes every keystroke live and shares the whole file. Emailing copies produces versions. Either way, one person's edit overwrites another's and nobody finds out until the number is wrong in a meeting.
2. No record of who changed what. A database logs every write. Excel's version history is a series of autosave snapshots with a timestamp and a name — not which cell changed, not what it was before, and never why.
3. The file is the unit of everything. You can't share the customer table without sharing the pricing tab next to it. You can't give Sales write access to their columns and Finance read access to the rest. One file, one permission.
4. No relationships. Orders reference customers; customers reference regions. In Excel that's a VLOOKUP that silently returns the wrong row when someone sorts one table and not the other.
What people replace it with — and what they give up
Access fixes relationships and multi-user editing for a small office, and is dying. Airtable is a real relational database with a spreadsheet-like face (no Excel); it's good, and it means rebuilding everything in a new tool with weaker formulas, no pivots and no offline editing. A proper database (Postgres, SQL Server) with an app on top is the correct answer for a transactional system — and a six-figure project for a customer list, and then every change requires an IT person to manage a project. In every case, the thing you give up is Excel: the formulas people know, the pivot they built, the model that's been tuned for three years.
Put the database behind Excel instead
There's a fourth option that most of the advice skips: keep Excel as the interface and put a database underneath it. That's what Symphony does. Each linked worksheet's data is stored in a database, not in the file. Excel stays exactly as it is — your formulas, your pivots, your formatting.
What the database gives you is the three things Excel couldn't. Multi-user updates without overwrites: everyone works privately and Submits when ready; teammates Refresh when they choose; conflicts are shown, never silently resolved. A log of every change: who, what, when and the reason attached — for any cell, row or worksheet. Sharing at the worksheet level: Invite someone to one tab; the rest of the workbook stays yours.
It doesn't do relationships between tables, and it isn't a transactional system. It's for the customer lists, order logs, budgets and forecasts that live in Excel because Excel is the right tool — and that break only because several people need to update them.
A monthly license for the whole team. Excel 2016 or later on Windows.
When to actually move to a database
Be honest with yourself here. If the data is transactional — orders being placed by a website, inventory decremented by a barcode scanner, records written by software rather than people — Excel was never the right home and neither is Excel-plus-anything. Build or buy the system. If the data is maintained by people, updated on a cadence, augmented, and analyzed in Excel, it belongs in Excel, and the fix is to make Excel safe for a team.
Related: how to merge Excel files — and when merging is the wrong frame · the six commands · Excel alternatives compared
Frequently asked
Can Excel be used as a database?
For one person and up to a few tens of thousands of rows, yes — a table with filters, lookups and pivots is a workable flat-file database. It stops working when more than one person needs to update it, when you need to know who changed a record, or when tables need to relate to each other.
How many rows can Excel handle as a database?
The hard limit is 1,048,576 rows per sheet. In practice, performance drops well before that — lookups and pivots over a few hundred thousand rows get slow, and the file gets large enough to be fragile. Most Excel 'databases' that cause trouble have under 20,000 rows; the problem is people, not size.
What's the difference between Excel and a database?
A database separates the data from the interface, lets many people update records at once without overwriting each other, enforces structure, and keeps a log of changes. Excel keeps data and interface in one file, treats every edit as final, and has no record of who changed what.
Is there a way to keep Excel but get database benefits?
Yes. Symphony stores each linked worksheet's data in a database while Excel remains the front end. You get multi-user updates without overwrites, worksheet-level sharing and a full change history, and keep your formulas, pivots and habits.