Quick insights
The whole report in five points.
- 01A practitioner who relied on Excel for 15 years migrated a client-and-order tracker to PostgreSQL in a single weekend using Docker and a Python script.
- 02Excel's data safeguards are entirely optional and manual, meaning foreign-key enforcement, non-null constraints, and type checks simply do not exist unless a user builds them by hand.
- 03The migration exercise of sketching normalized tables immediately exposed years of duplicate entries, inconsistent booleans, and orphaned references that Excel had been silently tolerating.
- 04PostgreSQL's constraints caught real data errors automatically: a duplicate customer email, a null order date, an orphaned payment reference, and a string typed into a currency field.
- 05After migration, a query that previously required an afternoon of VLOOKUPs and copy-pasting became a five-line SQL statement, and local LLMs can now query the database in plain language.
In one paragraph
The author used Excel as a de-facto database for 15 years across inventory, project tracking, and a homegrown CRM. The system eventually broke under its own weight -- cross-referencing three spreadsheets to answer a single question took an afternoon rather than 30 seconds. A weekend of containerized PostgreSQL setup and a small Python migration script replaced the brittle spreadsheet stack. PostgreSQL's schema constraints immediately caught data errors that Excel had been silently accumulating for years. The author still uses Excel for sharing data with non-technical collaborators but no longer treats it as a system of record.
What the report argues
The load-bearing claims, in the order the argument builds.
- Spreadsheet databases grow organically until they collapse under structural debt.
The author describes a pattern where a single sheet becomes three tabs, then ten, then a master file referencing half a dozen others. Formulas point at deleted cells, filters accidentally hide rows, and the accumulated damage is often invisible until the data is needed. This drift is not exceptional behavior -- the author frames it as the default trajectory for any spreadsheet used as a system of record.
- Excel's safety mechanisms are voluntary and easy to override, which makes them unreliable under deadline pressure.
Data validation rules and Power Pivot relationship modeling exist in Excel, but almost nobody configures them, and nothing prevents a user from overriding them later. There is no enforced equivalent of a relational foreign key. The author argues that every safeguard in Excel is a manual habit, and habits degrade precisely when workload is highest.
- The migration trigger was a single question that should have taken 30 seconds but took an afternoon.
Cross-referencing three spreadsheets to produce a client-invoicing answer required an extended session of VLOOKUPs and manual copy-pasting, and the author still was not confident the result was correct. This specific failure -- where the cost of retrieval became greater than the value of the tool's simplicity -- was the inflection point that prompted the switch.
- PostgreSQL can be containerized and running in under 10 minutes using Docker Compose with a named volume.
The author had existing Docker fluency from a home-server setup, which lowered the barrier. A Docker Compose file with a named volume for persistent storage was sufficient to stand up a working Postgres instance. The author also had prior exposure to Postgres from an unrelated project, giving the tool familiarity without formal database training.
- Thinking in normalized tables during migration immediately revealed years of hidden data quality problems.
The act of sketching a schema -- customers, orders, payments -- forced the author to confront duplicate records, inconsistent identifiers, and orphaned entries that had existed invisibly in the flat spreadsheet. A Python script using pandas and psycopg handled the export, cleaning, and import. The schema design exercise itself, not just the tooling, was a significant part of the value.
- Database constraints caught multiple real data errors that Excel had silently stored for years.
Specific errors caught included: a customer entered twice under the same email with a trailing space making it appear new (caught by unique constraint), an order with no date (caught by non-null constraint), a payment referencing a non-existent customer email (caught by foreign key), and the string 'paid in full' stored in a currency amount field (caught by type enforcement). These were not hypothetical risks -- they were real records in the migrated data.
- Post-migration, scheduled backups and LLM-based natural-language querying replaced manual save habits.
The author notes that backups now run on a schedule instead of depending on remembered manual saves. Additionally, local LLMs and Claude share access to the same Postgres database, allowing plain-language queries to replace SQL authoring for most routine data retrieval. This positions the database as an AI-queryable data layer, not just a storage improvement.
- Excel retains legitimate value for sharing data with non-SQL users but is not a system of record.
The author does not argue for eliminating Excel from the workflow. It remains useful for handing data to colleagues who are not comfortable with SQL queries. The core claim is narrower: Excel was never designed for the record-keeping role the author assigned it, and treating it as a persistent source of truth creates structural risk that accumulates slowly and fails unexpectedly.
Section by section
A walk through the source in its own structure. Collapse anything you do not need.
Spreadsheets quietly became my database
The author describes how Excel absorbed progressively more operational data over 15 years, including inventory, project tracking, budget management, and a hand-built CRM using conditional formatting and VLOOKUPs. The system worked until it did not. Growth created a web of cross-referencing files, broken formula references, and silent data corruption from accidental filter changes.
- A single spreadsheet expanded to ten tabs and then to a multi-file system with cross-references.
- Deleted cells left dangling formula references that were not immediately apparent.
- Accidental filter changes could hide rows with no obvious indication of data loss.
- Excel data validation and Power Pivot exist but are almost never configured, and can always be overridden.
- No enforced relational constraints exist -- every safeguard is a discretionary habit.
The breaking point: an afternoon for a 30-second question
The specific failure that prompted the switch was a client-invoicing lookup requiring manual cross-referencing of three spreadsheets. The process took an afternoon of VLOOKUPs and copy-pasting and still left the author uncertain about the result's accuracy. That friction made the cost of staying on Excel concrete enough to justify investigating alternatives.
- A single business question required reconciling three separate spreadsheets.
- VLOOKUPs and copy-pasting consumed an afternoon for a lookup that should take seconds.
- The author remained uncertain about the answer's accuracy even after completing the process.
- This specific failure served as the decision trigger for switching to a relational database.
Why PostgreSQL and how quickly it stood up
The author chose PostgreSQL for its ease of setup, Docker compatibility, and the ability to connect it to local LLMs for natural-language querying. Prior familiarity from an unrelated project reduced the learning curve. A Docker Compose file with persistent storage had a working instance running in under 10 minutes.
- PostgreSQL runs as a containerized service, fitting the author's existing Docker workflow.
- Docker Compose with a named volume provided persistent storage with minimal configuration.
- Initial setup took under 10 minutes.
- Existing LLM integrations could plug into Postgres directly, enabling plain-language queries.
- Prior experience with Postgres on a separate project provided familiarity without formal database training.
The migration process and what it exposed
The author migrated the messiest spreadsheet first: a client-and-order tracker. Designing the normalized schema -- customers, orders, payments -- immediately surfaced duplicate records and inconsistent data that had been invisible in the flat format. A Python script using pandas and psycopg automated the export, cleaning, and insertion.
- Starting with the most complex spreadsheet forced upfront schema design decisions.
- Normalized table design exposed years of duplicate entries, inconsistent identifiers, and missing relationships.
- A Python script using pandas for reading and psycopg for insertion handled the ETL process.
- Foreign keys and constraints were defined at schema creation time, not retrofitted later.
- The boolean invoice column had four variants (yes, no, true, N) and Postgres parsed most of them without manual intervention.
Constraints caught real errors immediately
On the first day of running against constraints, PostgreSQL rejected multiple real records that Excel had been storing without complaint. The rejections were not edge cases -- they reflected genuine data quality failures that had accumulated over years. Each rejection forced the author to find and correct the original entry rather than letting the error persist.
- A duplicate customer email with a trailing-space variant was blocked by the unique constraint.
- An order with no date was rejected by the non-null constraint.
- A payment referencing a non-existent customer email was rejected by the foreign key.
- The string 'paid in full' in a currency amount field was refused by type enforcement.
- Constraints force loud failures rather than silent corruption, which surfaces problems when they are still fixable.
Post-migration outcomes: queries, backups, and LLM access
After migration, the client-invoicing query that previously took an afternoon became a five-line SQL statement returning results on page load. Scheduled backups replaced manual save habits. Local LLMs and Claude share direct database access, allowing plain-language data retrieval without SQL authoring in most cases.
- A complex cross-spreadsheet query collapsed to five lines of SQL.
- A Flash dashboard renders the result immediately rather than requiring manual computation.
- Backups are now scheduled and automated rather than dependent on remembered manual saves.
- Local LLMs and Claude can query the same database via natural language, reducing direct SQL authoring.
- The database enforces rules the author previously maintained through memory and vigilance.
Excel's remaining role
The author does not abandon Excel entirely. It remains the preferred format for sharing data with collaborators who are not comfortable running SQL queries. The argument is against using it as a system of record, not against using it as a presentation or analysis layer. The closing reflection is that Postgres replaced not just a tool but a fragile mental model that had been patched for years.
- Excel is still used for sharing data with non-technical collaborators.
- It is not suited to serve as a system of record for data that must be reliable and queryable.
- The author's only stated regret is not migrating sooner.
- The switch required one weekend of effort for a 15-year accumulation of spreadsheet debt.
Why it matters
How CS Ventures reads this for client work. Interpretation, not the source's claim.
- Excel-as-database is a widespread, under-acknowledged liability in small operations
CS Ventures reads this as evidence that the Excel-as-database pattern is common across small operators and hobbyist businesses, not just unsophisticated ones. The author is a full-stack developer with over a decade of technical experience -- if he ran on spreadsheets for 15 years, the pattern is almost certainly more prevalent among less technical operators. Any service targeting small-business data infrastructure has a large, self-unaware addressable market.
- The migration barrier is lower than operators assume, which changes the sell
The author migrated a multi-year, multi-spreadsheet operation in a single weekend using freely available tooling. CS Ventures reads this as a signal that the technical friction is not the primary adoption barrier for Postgres or similar structured databases. The barrier is conceptual -- operators do not recognize their spreadsheet as a liability until a specific, costly failure makes the pain legible. Products that surface that latent pain (slow queries, data inconsistency, accidental overwrites) earlier in the user journey have an easier conversion path than those that lead with feature comparisons.
- LLM-queryable databases are becoming a practical expectation, not a premium feature
The author treats LLM access to the Postgres database as a routine quality-of-life feature, not a novelty. Local LLMs and Claude querying the same database in plain language is presented as a straightforward outcome of the migration. CS Ventures reads this as an early indicator that AI-native data access -- where structured data is queryable by language rather than by SQL literacy -- is moving toward a baseline expectation for small operators adopting any new data infrastructure.