Airtable, Google Sheets or a real database: what to store data in

Too small.

That's the usual excuse for starting a client build in Google Sheets. The truth is closer to the opposite: spreadsheets fail on data that's too important, not too small. A spreadsheet has no concept of a required field, a valid status, or a relationship between two records. A quote number can get typed twice, a status column can say "Compete" instead of "Complete", and nothing stops it. One recurring pattern across client builds is a spreadsheet that's been driving quotes or scheduling for years, silently accumulating small errors nobody notices until an automation tries to read it and chokes on the inconsistency. The fix usually isn't a database migration. It's Airtable.

What Airtable actually buys you

Airtable sits in a specific gap: it looks like a spreadsheet so a non-technical client can still open it and understand what they're looking at, but it enforces field types, supports linked records between tables, and gives you views (Kanban, calendar, grid) without writing a query. That combination matters more than any single feature. A roofing business with ten thousand dormant leads, a veterinary practice juggling ten rooms and eleven overlapping schedules, a membership operation tracking active versus lapsed billing status: none of these need a custom-built database to get real value. They need the data to stop lying to them, and Airtable's built-in validation does that at a fraction of the cost and setup time of Postgres or Supabase. It also has a real API and works cleanly with Make or n8n, which matters once the goal is automation rather than just storage.

Where a real database earns its complexity

A structured database like Postgres wins once you have relationships and volume that Airtable's row-and-attachment model starts to strain under, or once you need transactional integrity that a workflow tool can't guarantee (billing systems, anything touching money, anything where two processes might write to the same record at once). It also wins when the data itself isn't rows and columns. Unstructured knowledge, retiring-employee expertise, document search, anything you want an AI to search by meaning rather than by exact match, belongs in a vector database, not a relational one and not Airtable.

The mistake to avoid here is the inverse one: reaching for a vector database to solve a problem that's actually a simple structured lookup. If the data has clear fields and clear relationships, a normal query beats an embedding search every time, and it costs less to build and debug.

The actual decision rule

Start with what the client can see and touch. If nobody on the team can read a database schema, Airtable is the only realistic choice for an MVP, because a system nobody can inspect is a system nobody will trust or maintain. Move to a dedicated database when you hit real volume, real concurrency, or a genuine need for unstructured or semantic search, not before. And treat a spreadsheet as a temporary holding pattern only, useful for a first pass at understanding a workflow, never as the backbone of anything you're asking an automation to depend on. The build order that keeps working, project after project, is spreadsheet-to-Airtable-to-database only when the evidence demands it, never database-first because it feels more serious.