It starts innocently enough. You’ve got a spreadsheet tracking horse trip notes, consultant CVs, or inventory data. It works fine until it doesn’t. VLOOKUPs are getting unwieldy. Multiple people are editing conflicting versions. You need to filter, search, and actually trust the data.
The solution seems obvious: move it all into a proper database.
This is where most small firms die.
Not from the technical work of setting up PostgreSQL or Airtable. They die from the hidden complexity tax that nobody warned them about. The database won’t be the problem. The GUI will be the problem. And by the time you realize that, you’re already three months deep in a project that was supposed to take a weekend.
Here’s what nobody tells you about the journey from Excel to database, and how to survive it.
The Truth Nobody Wants to Hear
When that Reddit user posted about wanting to move horse trip notes from Excel to a database, the responses were telling. The top-voted comment didn’t recommend a database at all. It warned about the GUI. “The database won’t be the problem. The problem is the gui. You’d be building out an app just to do the same thing.”
That’s the dirty secret. A database is just a storage engine. It has no interface, no filters, no dropdowns. The magical filtered view you had in Excel? That was the Excel application, not the data. When you move to a database, you lose all of that instantly.
What you actually need is not a database. You need a data application with a database underneath. And building a data application from scratch, even a simple one, is a full-time project for someone who actually knows what they’re doing.
The original poster wanted a dropdown to select a horse’s racing day and have the relevant notes auto-populate. That’s not a database problem. That’s a frontend problem. And unless you’re willing to build a full UI, you’re better off keeping the spreadsheet.
The No-Code Trap
The natural reflex is to reach for a no-code tool. Airtable, Stackby, Notion, Coda. These products are designed exactly for this scenario: they look like spreadsheets but behave like databases.
No-code databases in 2026 have gotten remarkably good. They offer structured data models, relationships between tables, automation triggers, and AI-powered features. Stackby, for instance, promises a “hybrid spreadsheet-database” with 50+ API connectors and 1000+ pre-built templates. Airtable has AI agents and document extraction.
| Tool | Key Features | Best For |
|---|---|---|
| Stackby | Hybrid spreadsheet-database, AI features, 50+ API connectors | Versatile all-rounder for teams |
| Airtable | Flexible data modeling, AI agents, enterprise features | Larger teams needing advanced schema management |
| AppSheet | Turns spreadsheets into apps | Users with existing spreadsheet data |
| Notion | All-in-one workspace, inline databases | Personal use and small teams |
These tools are genuinely powerful. But they come with a hidden cost: platform dependency. The moment you build your entire workflow in Airtable, you’re locked into their pricing, their feature limitations, and their uptime. When they raise prices or deprecate a feature you depend on, you have two options: pay up or rebuild.
And that “simple” hobby project you started? It now costs $20 per seat per month. For four users. For something that used to live in a free Google Sheet.
This is why many consulting companies that migrated from Excel to centralized CV platforms found the actual migration was the easy part. The hard part was cleaning up years of accumulated data inconsistencies. As one operations lead noted, “the data quality problem hidden in your CVs” surfaces all the inconsistencies that Excel tolerated but a structured database cannot.
What Migration Actually Looks Like
Here’s what a real migration looks like, based on companies that have actually done it successfully:
Phase 1: Data Audit (2-5 days)
You cannot migrate what you do not understand. Open your Excel files and look for:
- Inconsistent naming conventions (e.g., “UK” vs “United Kingdom”)
- Empty cells where data should exist
- Duplicate records that accumulated over years
- Mixed data types in single columns
Phase 2: Schema Design (1-3 days)
This is where most amateurs go wrong. In Excel, you can throw everything in one sheet and add columns as needed. In a database, you need to define:
- Tables and their relationships
- Primary and foreign keys
- Data types for every column
- Constraints and validation rules
The original poster’s need, selecting a horse’s racing day and pulling previous notes, requires at minimum two tables: one for horses and one for trip entries, linked by a horse ID. That’s a one-to-many relationship that Excel handles poorly but databases handle natively.
Phase 3: The Parser Problem
If you’re importing from an existing tool that exports data in a non-standard format, that export step is often where the most time is lost before migration even begins. Building a dedicated parser for that specific format is part of the migration work, and it is reusable for any future imports from the same source.
Here’s a practical example: Most companies using Excel files or basic tools end up with one large, undifferentiated list. Active consultants, former consultants, candidates in process, and applicants who submitted a CV once and never followed up, all in one file. Separating these groups is often the first structural improvement when migrating to a proper system.
Phase 4: Validation (1-2 days)
The most reliable approach is to validate with one or two profiles before committing to a full load. As one migration guide put it, “A first profile can be validated and live within hours. A full database migration can be completed in a single morning once the parser is confirmed.”
| Scenario | Without Separation | With Separation |
|---|---|---|
| Checking available skills | Scroll through everyone, filter manually | View only active consultants by skill |
| Reporting | Counts include inactive records | Accurate headcount and skills breakdown |
| Search | Inflated by unverified claims | Based only on verified experience |
When Excel Is the Right Answer
Here’s the uncomfortable truth: for a single user tracking horse trip notes, an Excel spreadsheet is probably the correct solution.
The friction of setting up a database, even a simple one, outweighs the benefits when:
- Only one person accesses the data
- You have fewer than 500 records
- The data structure changes frequently
- You don’t need concurrent editing
- The cost of a mistake is low
The threshold where a database becomes worthwhile is roughly when you hit one of these:
- Multiple people need to edit simultaneously
- You need complex queries across related data
- Data integrity is critical (e.g., financial records)
- You’re spending more time managing the spreadsheet than using it
A Decision Framework
Ask yourself these questions before moving:
- Do I need concurrent editing? If yes, consider a database. Excel’s co-authoring is fragile.
- Do I need to query across related datasets? If yes, a database provides real power. Excel’s VLOOKUP gets painful at scale.
- Can I tolerate data corruption? If no, use a database with constraints and validation.
- Do I have development resources? If no, stick with spreadsheets or invest in no-code tools.
- How much is my time worth? If building the database costs 40 hours and saves 2 hours per week, you break even in 20 weeks. Be honest about that calculation.
The Unsexy Path
If you’ve decided you genuinely need a database, here’s the most practical path for a non-developer:
Option 1: No-Code Platforms (Recommended)
Platforms like Airtable, Stackby, or Notion handle both the database and the interface. They’re not perfect, but they’re infinitely better than building from scratch. The key is to start small and avoid over-customization. Pick a tool, use their templates, and resist the urge to make it perfect. Configure fields to match your existing schema and import your data. Choosing the right client tool is important but secondary to getting the data structure right.
Option 2: SQLite + a Side Project
If you’re technically inclined and want to learn, SQLite is the simplest real database. It requires no server, no installation, and no ongoing costs. You manage it through a lightweight frontend like Datasette or SQLite Browser. This is the path for hobby projects and personal tools.
Option 3: Managed Database + App Builder
For small teams, a managed PostgreSQL instance (from Supabase, Railway, or similar) plus a low-code frontend (like Retool or Budibase) gives you real database power without building everything from scratch. PostgreSQL remains the dominant choice for good reason, it scales from hobby projects to enterprise workloads.
The Real Cost of Not Migrating
There’s another side to this equation that doesn’t get enough airtime. The cost of not migrating.
For consulting companies managing hundreds of consultant CVs across Excel files, the cost is invisible but real. Someone on the operations team is spending their morning correcting data that the system failed to capture. They’re chasing consultants for updates. They’re reformatting the same CV for the fifth time this month because each client submission requires a different template.
The problem isn’t that Excel is bad. The problem is that the process built around it accumulates friction. Each additional consultant, each new client requirement, each added data field makes the Excel file slightly worse. The team learns to work around it, which means the cost becomes normalized.
At a certain point, usually around 50 consultants or 3 simultaneous projects, the spreadsheet stops being a tool and becomes a constraint on growth. Many small firms collapse at exactly this transition, not because they didn’t see it coming, but because they underestimated what the fix would cost.
The Verdict
Moving from Excel to a database is not a technical problem. It’s a systems design problem that happens to involve technology. The naive approach, “just use SQL” or “just use Airtable”, fails because it ignores the interface, the data quality issues, and the maintenance burden.
For hobby projects and single-user tracking, keep the spreadsheet. You’re not outgrowing it as fast as you think. The productivity loss from managing data in Excel is often dwarfed by the productivity loss from building and maintaining a database application.
For growing teams with real operational needs, skip the homegrown database entirely. Use a purpose-built tool or a no-code platform that’s designed for your use case. The companies that successfully navigate this migration do it by choosing the right starting point, a single validated record, and scaling from there. The whole company can be onboarded in a single morning if the data structure is right.
The best database is the one you don’t have to build yourself. The best migration is the one where you spend more time on data quality than on infrastructure. And the best outcome is when you stop thinking about how your data is stored and start thinking about what it enables.
If you’re currently managing 47 Excel files and updating them 120 times per week, you’ve already crossed the line. The question isn’t whether to migrate. The question is how much of your business you’re willing to burn learning that lesson the hard way.
