Short answer: Design Airtable bases around one table per real-world entity, link tables rather than duplicating data, use the strictest field type that fits, keep formulas shallow, control entry points, name fields for machines as well as humans, plan for volume before you hit it, and document the schema. Most Airtable performance and accuracy problems trace back to violating one of these in the first week.
Tables should map to real things: Companies, Contacts, Projects, Invoices, Properties. Not to states or reports — "Active Clients" and "Past Clients" should be one table with a status field, not two tables. The test: if a record could ever move between two of your tables, they should be one table.
If a project needs the client's address, link to the client record and use a lookup. Do not type the address into the project. Duplicated data diverges the moment either copy changes, and in Airtable the divergence is silent — nothing warns you that two records now disagree.
The corollary: if you find yourself pasting the same value into many records, you're missing a linked table.
Single select over text. Date over text. Number with precision set over text. Checkbox over a single-select with Yes/No. Every loosening of a field type is a future data quality problem, because free text accumulates variants that break filters, groupings and automations without error messages.
Where the options genuinely vary, use single select with a locked option list and a controlled process for adding options.
Formulas referencing formulas referencing rollups create dependency chains that recalculate slowly and are almost impossible to debug. Two levels is comfortable, three is a warning sign, four means you should be computing this elsewhere — in an automation that writes a static value, or in a reporting layer.
A base where anyone can type into any field in any table will degrade. Define how records get created — a form, an interface, or an automation — and make the raw table view an admin surface rather than a working one. Airtable's Interface Designer exists for precisely this, and it's underused.
Field names appear in API calls, automation mappings and formulas. Avoid emoji, leading spaces, and names that change meaning over time ("Status 2", "New Status"). Renaming a field later means touching every automation that references it. Pick names you can live with and keep them stable.
Airtable's per-base and per-table record limits are generous but real, and views with many linked lookups slow down well before you hit them. If you're loading a dataset that will run into hundreds of thousands of rows, consider whether Airtable is the operational layer and a warehouse like BigQuery is the analytical one, rather than trying to make one tool do both.
Maintain a short document listing each table, what it represents, its key fields, its relationships and the automations that touch it. This takes an hour and saves days — most notably when the person who built the base is unavailable and something breaks.
Structural discipline isn't aesthetic. It determines whether you can automate reliably, whether your reports reconcile, whether you can migrate later, and whether AI applied to this data produces anything trustworthy. A well-structured base with modest features beats an elaborate one built on a flat table every time.
As many as you have entities — commonly five to twelve for an operational base. Dozens of tables usually indicates entities being split by state, which is Rule 1.
One base per operational domain. Records can't link across bases, so anything that needs relationships must live together.
When record volume consistently strains performance, when you need genuine multi-user concurrent transactional integrity, or when analytical queries become the primary use. For most SMEs, none of these arrive.
We've migrated CRMs of 45,000+ companies into structured Airtable systems. See how.