Replacing Excel: When Your Spreadsheet Should Become a Real Database

Almost every Excel "database" started innocently: a list, a few formulas, eventually a macro. The trouble begins at recognizable points. First: multi-user conflicts. Messages like "File is locked by ...", overwritten changes, or customer and invoice numbers assigned twice all show that several people are working with a tool that was never built for it.

Second: version chaos. When files named "List_final_v3_NEW.xlsx" circulate by email, nobody knows which version is authoritative anymore. Third: macros that stop working after an Office update or a new computer. Fourth: the single point of knowledge — exactly one person understands the file, and at some point that person is on vacation or gone. Fifth: personal data (customers, applicants, employees) sits in a file with no access controls, no audit log, and no deletion policy. If more than one of these signs applies, replacement is worth the investment.

The research is unambiguous, even if the best-known numbers are older. Raymond Panko (University of Hawaii) found in the classic body of studies that 94% of 88 operational spreadsheets examined contained at least one error; the average cell error rate ranged from just under 2% to around 5% depending on the study. A later, more conservative analysis of 50 production workbooks with more than 270,000 formulas still found 1.79% of formula cells to be faulty. Worse: in manual review, people catch only 50–80% of the errors that are actually there.

That this causes real damage is well documented. In October 2020, Public Health England lost roughly 16,000 COVID cases from its reporting chain because a CSV import into the legacy .xls format was cut off at the 65,536-row limit — delaying contact tracing accordingly. And in JPMorgan's "London Whale" loss (around $6 billion, 2012), a copy-paste-driven Excel risk model with a formula error was one of several factors that understated the actual risk by roughly half. The point is not that Excel is bad — it's that Excel has no mechanisms to prevent such errors or make them visible.

Microsoft has deprecated the classic "shared workbook"; it doesn't support formatted tables, severely restricts macros, and conflicting changes have to be resolved by hand at save time. The more modern co-authoring in Microsoft 365 only solves simultaneous typing. What it does not solve: input validation, row- or field-level permissions, referential integrity between tables, clean versioning, and an audit trail of who changed what and when. Yet those are exactly the requirements once data becomes business-critical.

With personal data, the GDPR enters the picture. Bavaria's data protection authority dedicates an entire guidance note (No. 46) to Excel mishaps: the typical case is hidden columns, rows, or worksheets containing personal data that get sent along unnoticed — in the worst case a reportable data breach under Article 33 GDPR. Structurally, Excel also lacks everything the accountability principle (Article 5(2) GDPR) demands: no record-level permission model, no access logs, no workable deletion policy. HR lists with salaries or sick days in Excel are therefore a real regulatory and liability risk.

Access has not been discontinued — but Microsoft has largely stopped developing it; for years, updates have essentially been limited to bug fixes and security patches. On support specifically: for Access 2016 and 2019, it expired in October 2025; for Access 2021, it ends in October 2026; Access LTSC 2024 runs through October 2029; and the Microsoft 365 version continues to be maintained. Anyone running a business-critical Access application on 2016/2019 is already operating without security updates.

Migrating to PostgreSQL is feasible but not a push-button exercise: data types have to be mapped, SQL queries adapted to a different dialect, and VBA code with Jet-specific assumptions handled case by case. A proven intermediate step: replace only the backend — the Jet/ACE file — with PostgreSQL and keep the Access frontend for now. That eliminates the typical file corruption and the multi-user problems without requiring a full rebuild right away.

The usual replacement is a central PostgreSQL database with a lean web interface tailored to how your business actually works. That gives you what Excel structurally cannot: a single source of truth, concurrent editing without conflicts, required fields and validation at data entry, roles and permissions down to the record level, automatic change logging, and managed backups. Links between customers, orders, and invoices are no longer chains of VLOOKUPs but real relations with referential integrity.

SaaS alternatives like Airtable exist, but they mean ongoing per-user monthly costs — with ten users, quickly a four-figure annual bill — and your data sits with a US provider, which requires its own GDPR assessment. Open-source tools like Baserow or NocoDB can be self-hosted and put a spreadsheet-like interface on top of a PostgreSQL database; for simple cases, that is a legitimate route. A custom-built solution costs a one-time project budget instead of a perpetual subscription, and the data stays in-house. Excel doesn't have to disappear either: as a reporting frontend connecting to the database via Power Query or ODBC, it remains a fine tool — just no longer the data store.

A realistic project has five steps. First, inventory: which tables, formulas, and macros do what — and which of them are actually still needed? In practice, a portion drops out at this stage already. Second, the data model: the organically grown sheets become clean tables with keys and relations. Third, data cleanup — duplicates, inconsistent spellings, and orphaned entries inevitably surface here; it's work, but exactly the effort that pays off later. Fourth, the web interface for data entry and reporting. Fifth, a period of parallel operation before the old file is switched off.

On costs at QubeLogix (net prices; as a German small business under § 19 UStG, no VAT is charged): replacing a single Excel or Access solution starts at €2,500. A multi-user database with a web interface, permissions, and reporting typically runs €6,000–12,000. Timewise, think in weeks, not days — the effort is rarely in the technology itself, but in understanding the accumulated logic and cleaning up the data.

An honest counter-check: Excel is the right tool for many jobs, and replacing it in those cases would be wasted money. Stay with Excel if only one person works with the file, it holds a few hundred to a few thousand rows, it contains no personal data, and it needs no links to other datasets. For ad-hoc analysis, calculations, what-if modeling, and quick prototypes, Excel is unbeatable — that's what it was built for.

The rule of thumb: Excel is a calculation and analysis tool, not multi-user data storage. As long as you're calculating and analyzing, keep it. Once several people maintain the same data, business processes depend on it, or the GDPR has a say, a database is the cheaper option — measured by the cost of the errors, not the price of the project.