Airtable

A relational database wearing a spreadsheet's face - the strongest tool in the category for teams whose data has shape but whose team has no engineers.

Verdict

Airtable is the clearest answer in its category to a specific problem: a team's data has genuine structure - records that belong to other records - and the people who own that data are not engineers. It gives them a relational model with a spreadsheet's learning curve, and the linked-record field is the feature everything else hangs off. The honest caveats are all about what happens as you succeed with it. Per-seat pricing means the tool gets more expensive precisely as more of the team depends on it, including people who only read; the record and attachment ceilings on each tier are the real constraint rather than the feature lists; and a base that grows without someone owning its schema turns into the thing it replaced. This grade comes from vendor documentation, pricing structure and verified user reports, against the published rubric; no first-hand testing was run and none is claimed.

Visit Airtable
We have no affiliate relationship with this vendor. Link goes to the official site.

What the product actually is

Airtable is a relational database with a spreadsheet interface. That sentence is the whole product and it is worth unpacking, because the two halves pull in different directions and the tension between them explains both the appeal and the complaints.

The relational half means a record can point at another record. A row in a table of projects can hold a link to a row in a table of clients, and the client's name, contact and contract terms live in exactly one place. Change the client's email once and every project referencing it reflects the change. This is the thing spreadsheets cannot do: a spreadsheet can hold the client's email in forty rows, and forty is the number of places it can be wrong.

The spreadsheet half means the interface is a grid you can click into. Columns have types, rows are records, and the learning curve starts from something almost everyone in an office already knows. There is no schema migration step, no query language required for ordinary work, and no deployment.

What you are buying is therefore the relational model delivered to people who would never install a database. That is a narrower proposition than the marketing suggests and a genuinely valuable one.

Who it is for, and who it is not

The fit is sharp. This suits a team whose data has real structure and whose team has no engineering capacity: content calendars where each piece has an owner, a channel and a campaign; applicant pipelines where each candidate has a role and several interview records; inventory where each item has a supplier and a location; grant or client trackers where each engagement has documents, deadlines and people attached.

The common thread is that the data is relational in reality and has been forced flat by a spreadsheet. The moment someone on the team starts maintaining a second tab that is really a lookup table, the structural case for this product has already been made.

It is the wrong tool in three cases, and all three are reported consistently. It is wrong for a team whose data is genuinely a single flat list, because a spreadsheet is faster, cheaper and more universally understood. It is wrong as an application database behind a customer-facing product, because the per-record and per-request characteristics are not designed for that and the pricing model punishes it. And it is wrong for a team that will not appoint someone to own the schema, for reasons set out further down.

If the main job is task and project management with dates, owners and dependencies rather than records with relationships, the Asana review covers the tool shaped for that problem instead.

How the pricing is structured

We did not verify current prices against the live pricing page for this grade, so there are no figures here. What follows is the structure, which changes far more slowly than the numbers and is the part that decides your eventual bill.

There is a free tier with hard caps on records per base and on attachment storage, plus limits on automation runs and on how far back revision history goes. Above it sit per-seat tiers, and each step up raises those same ceilings while adding capability: more automation runs, longer history, more control over permissions, and at the upper end administrative and security features aimed at larger organisations.

Two structural facts matter more than any price. First, billing is per seat and the tiers most teams actually need do not have a free read-only role, which means colleagues who look at a base without editing it still cost money. Second, the ceilings are per base rather than per account, which shapes how you design: one enormous base hits a wall that three smaller related bases would not, and splitting them later is real work.

So the question to answer before committing is not what the monthly figure is today. It is how many people will eventually need access, how many of them only read, and roughly how many records the data will reach in two years. Read the current tier table on the vendor's own pricing page against those three answers.

Ease of use: the first two weeks

Onboarding is the strongest part of the product and the reason it spread through operations teams without procurement involvement. A new user who knows a spreadsheet can create a table, type into it and produce something useful inside an hour, and nothing about the first hour requires understanding the relational model at all.

The curve appears at the point where the relational model becomes necessary, and it appears as a conceptual step rather than a technical one. Linked records, lookups and rollups are three ideas that have to land together: the link creates the relationship, the lookup pulls a field across it, and the rollup aggregates across it. Users who absorb those three think in bases afterwards. Users who do not end up pasting values between tables, which reproduces the spreadsheet problem inside a database.

The documentation and template gallery do real work here, and verified user reports consistently credit them. Templates are the most effective teaching mechanism the product has, because they show a correctly normalised base rather than describing one.

Ease scores just above four rather than higher because of that conceptual step. Nothing about it is badly designed; it is simply the point at which a database stops pretending to be a spreadsheet, and a meaningful share of teams never cross it.

Features: depth of the core job

The core job is modelling structured data and showing it usefully, and the depth here is the reason the product grades well on features.

Field types cover the ordinary cases plus the ones that matter for operations work: attachments, single and multiple select, collaborator, date with time zone handling, formula, and the linked-record type that makes the whole thing relational. Views are saved configurations over the same records rather than copies, so a grid for the person maintaining the data, a kanban for the person running the process and a calendar for the person planning the month are three windows onto one truth. That single fact prevents the most common spreadsheet failure, which is three versions of the same list.

Forms write directly into a table, closing the gap between a request arriving and a record existing. Automations handle the recurring work: when a record enters a state, send a message, create a record elsewhere, update a field. Interfaces let someone build a simple front end over a base so that a colleague can do their part without being handed the raw grid.

What is deliberately shallow is reporting. There are summaries, groupings and charts, and they are adequate for operational questions. They are not a replacement for a business intelligence tool, and the documentation does not claim otherwise.

Integrations and what to verify before committing

There is a published REST API, webhooks, an automation layer with connectors to common services, and support from the general-purpose integration platforms that sit between software products. For most teams the practical integration story is good, and it is rarely the reason a deployment fails.

Five things are worth verifying against current documentation before you commit, because all five are the kind of detail that decides a project and none of them is visible on a feature comparison. What are the API rate limits on the tier you intend to buy, and does your intended sync pattern fit inside them? Which automation actions are gated behind higher tiers? What does the export path actually produce, and does it preserve the links between tables or flatten them? How are attachments handled on export, given that they are stored rather than referenced? And what are the permission granularities on your tier, specifically whether you can give someone access to one table rather than a whole base?

That last one comes up repeatedly in verified user reports. Permission models in this category are usually coarser than teams expect, and discovering the granularity after the base has been designed around an assumption is an expensive discovery. Read it first.

Support and documentation

Documentation is thorough and well organised, with a help centre that covers the conceptual material as well as the mechanical, and a template gallery that functions as applied documentation. For a product whose main adoption risk is a conceptual step, that is the right place to have invested.

Support itself follows the pattern of the category. Lower tiers are routed to self-service and asynchronous channels; faster response commitments and named contacts appear at the upper, organisation-scale tiers. Verified user reports describe the experience as competent on mechanical questions and less useful on design questions, which is expected: no support desk can tell you how to normalise your schema, and that is where most of the real difficulty lives.

There is an active community and a substantial body of third-party material, which in practice is where schema design questions get answered.

Support scores just under four. The documentation deserves better than that on its own, but the grade has to reflect the realistic experience of a team on a mid-tier plan with a design problem, and for them the answer is a forum rather than a response time. Read the current support terms for the tier you intend to buy rather than the headline support page.

What verified user reports consistently say

Four themes recur across independent sources, and they are consistent enough to treat as characteristics rather than opinions.

The first is that it genuinely replaces the spreadsheet, and the relief is specific: one place for the client, one place for the status, and no reconciliation meeting. This is the most common positive and it maps precisely onto the linked-record feature.

The second is that cost becomes the problem later rather than sooner. Teams adopt it on a free or cheap tier, succeed with it, invite more colleagues, and then discover that success is what the per-seat model charges for. Reports describe this as the main source of regret, and it is predictable at the point of purchase rather than hidden.

The third is hitting ceilings. Record and attachment limits are reached by bases that grew naturally, and the remedy involves either paying up a tier or restructuring, both of which arrive at an inconvenient moment.

The fourth is schema rot, discussed in its own section below. Reports describe wide tables, duplicated columns and abandoned views in bases nobody owns. This is the only one of the four that is the team's doing rather than the product's, and it is the most damaging.

Where it falls short, stated without hedging

Value is the score to explain, because it sits lowest at just above three while features sit near the top. That gap is the honest summary of this product. The capability is real and the pricing model charges for exactly the thing that indicates the capability is working, which is more people depending on it. Billing per seat for read-only colleagues is the specific mechanism, and on the tiers that unlock the features most teams need there is no cheap viewer role to escape into.

The second shortfall is the ceilings. Record and attachment caps per base are the genuine constraint, and a feature comparison between tiers hides this because features are interesting and limits are not. Any team whose data grows should model two years of growth against the caps rather than against the feature list.

The third is schema rot, and it is the one that destroys deployments. A base with no owner accumulates columns: someone adds a field rather than asking where it belongs, someone else adds another because they cannot find the first, and within a year the table is wide, duplicated and worse than the spreadsheet it replaced. The product gives a team the power to build structure and no mechanism to force anyone to maintain it. Appointing one person to own the schema is not optional, and teams that skip it report the failure rather than the tool reporting it.

Fourth, it is not a transactional database and not a warehouse. Pushing it toward either produces friction, and the documentation is honest about this even where enthusiasm is not.

Alternatives and adjacent tools

Within this site, the nearest neighbour is the project-management category rather than another database. The Asana review covers the tool to buy when the job is work with owners, dates and dependencies rather than records with relationships, and the distinction is worth taking seriously because teams regularly buy one for the other's job and then blame the result.

Outside our coverage, three directions are worth naming without grading. A plain spreadsheet remains the right answer for genuinely flat data and should not be dismissed as a downgrade. The newer document-database hybrids compete directly on the same relational-plus-friendly-interface premise with different trade-offs on price and depth. And a managed relational database behind a low-code front end is where teams land when the data outgrows this category entirely, at the cost of needing somebody technical.

We will not rank what we have not scored against the published rubric, so these are categories rather than recommendations. The practical advice when comparing within this space is to compare on four things: the permission granularity, the per-tier ceilings, what the export actually preserves, and whether read-only colleagues cost money. Feature lists in this category are more similar than they look; those four are where the products genuinely differ.

Frequently asked

Is it a real database? Relationally, yes: records link to records and a value lives in one place. It is not a transactional database for an application, and it is not designed to be.

Can the free tier run a small team? For a small base with few attachments, yes, and it is a reasonable way to test the fit. The caps on records and attachments are what you will meet first, not the feature omissions.

Do read-only colleagues cost a seat? On the tiers most teams need, yes. This is the single most important thing to model before committing, and it is the most common source of reported regret.

What happens at the record ceiling? You either move up a tier or restructure into smaller linked bases. Designing for that possibility early is cheaper than reacting to it later.

Can data be exported? Yes, and the question that matters is what the export preserves. Check how links between tables and stored attachments come out before you depend on it.

Does it replace a reporting tool? No. Summaries and charts answer operational questions; analytical reporting belongs elsewhere.

What kills deployments? Not the product. An unowned schema, every time.

Does this page earn a commission? No. There is no affiliate relationship behind this grade and the score would be identical either way.

The grade, and what would change it

Features sit near the top of the scale because the relational model, the views-as-queries design, forms, automations and interfaces together solve a real problem that the alternative does not solve at all. Ease sits just above four because the first hour is genuinely easy and the conceptual step from spreadsheet thinking to relational thinking is genuinely a step. Support sits just under four, with excellent documentation pulling against a realistic mid-tier support experience. Value sits lowest, because a per-seat model that bills for readers charges most from the teams for whom the product is working best.

Three changes would move the grade. A durable free or low-cost read-only role on the mid tiers would raise value materially, because it would decouple the bill from the breadth of adoption. Finer permission granularity below the base level would raise both features and value, since it is the limitation verified user reports hit most often after the ceilings. And clearer per-tier limit disclosure alongside the feature table would reduce the commonest form of buyer surprise.

What would lower it is simple: tightening the free tier further, or moving existing mid-tier capability upward. Both are normal in this market and both would be visible in the pricing page history.

This grade comes from vendor documentation, pricing structure and verified user reports, scored against the published rubric. No first-hand testing was run and none is claimed.

Visit Airtable
We have no affiliate relationship with this vendor. Link goes to the official site.