Looking for an Airtable alternative? Read this first
Most people searching for an Airtable alternative are hitting one of four specific walls. Identify which one, because it determines whether switching helps at all.
Airtable did more than any other product to make relational data approachable, and much of this category exists because it proved the idea. If you are looking for an alternative, it is usually not because the concept is wrong — it is because you have hit a specific wall, or because the news made you audit what you depend on.
There are four common walls, plus one event. Which one brought you here determines whether switching will actually help, so it is worth being precise before you start trialling things.
A note on specifics: pricing and plan limits in this category change several times a year. This article compares on structure — how the tools model data and permissions — because that is what stays true. Check current pricing and limits directly with each vendor before deciding.
Wall 1: cost as the team grows
The most common one. These tools generally charge per user per month, and the features that make a workspace safe for a wider group — granular permissions, admin controls, audit — usually sit on higher tiers.
The pattern: a small team adopts on a cheap plan, it works, more people need access, and the per-seat cost multiplied by the tier upgrade is suddenly a real line item.
Before switching, check whether you actually need every seat to be a full editor. Many people only ever read, or only ever submit through a form. If a tool offers free or cheap read-only and form-only access, restructuring who has what kind of seat can be a bigger saving than migrating.
If you have already done that and it is still too expensive, cost is a legitimate reason to move — but compare on your seat mix at your projected size, not on headline price.
Wall 2: relation depth
The one that catches people modelling seriously, and the one demos never show.
Every tool in this category links two tables. The question is what happens on the second and third hop. Can a line item show its order's customer's account manager? Can you roll a total up through two levels — line items to orders to customer lifetime value?
Where a tool only traverses one hop, you work around it by copying fields down a level to bridge the gap. That reintroduces exactly the duplication you left spreadsheets to escape, and it drifts the same way.
The same job, both ways
Take a question operations teams ask weekly: which supplier does this order depend on?
Three hops, and nothing exotic about them — an order has line items, a line item names a product, a product comes from a supplier. It is the shape of every business that resells anything.
Where a tool stops at one hop, you get there by adding columns whose only job is to shorten the path:
| Table | Column you add | What it is for |
|---|---|---|
| Line items | Supplier (from Product) | so the next level up can see it |
| Orders | Suppliers (from Line items) | so the order can see it at all |
Neither column answers a question anyone asked. They show up on every row, in every CSV, in every form that lists the table's fields, and on the screen of every person who has never once cared about suppliers. Ask a second question — which region is that supplier in? — and you add a third.
In RowFold you name the route once, on the single view that needs it:
Order → Line items → Product → Supplier
No new column, on any table. That order's grid shows the supplier, nobody else's screen changes, and a product that switches supplier updates every order that ever used it — because nothing was copied anywhere to go stale. Routes run up to five hops, and conditions travel them too, so only the orders whose supplier is in the south west is the same one-line move.
This is a house rule rather than a feature we happen to have: never create a bridging column whose only job is to make a route legal. Clutter on every row and in every export is the cost, and a relational model should be saving you from it, not charging you for it.
How to test it on any tool, including this one: take your genuinely hardest relationship — usually a junction table with parents on both sides — and try to surface a value three hops away without adding a column to anything. If you cannot, and your model needs it, no amount of other features compensates.
Wall 3: permissions granularity
"Can open the base" is not permissions.
The questions that matter:
- Can someone see only their own rows?
- Can a field be hidden from a role while still working in calculations?
- Can you give read access without the ability to export everything?
Field-level control is the line between "we can give the contractor access" and "we cannot". If your data includes salaries, margins, or anything covered by a client confidentiality clause, this is often the actual blocker — and it frequently sits on the most expensive tier.
The one that is not on the feature list
Somewhere past the modelling walls there is a fourth thing, and it rarely appears in a comparison because it is hard to put in a table cell: the point where a record represents a commitment. A price that goes out, money leaving, a document somebody will be held to.
At that point a status field called Approved stops being enough, because anyone who can edit the record can write it, and editing an approved record leaves it approved. The test is one line long — approve something, then change it — and most tools in this category fail it.
If your model has records like that, evaluate on it deliberately: Approval workflows that actually hold sets out the eight questions worth asking of any tool, this one included.
Wall 4: it became a database and you needed an application
Sometimes the tool is fine and the requirement changed. If you now need a public-facing product, thousands of concurrent users, or sub-second queries over tens of millions of rows, you have outgrown the category rather than the vendor.
Switching to a similar tool will not help. That is a Postgres-and-a-front-end problem.
Be honest about which situation you are in. Migrating sideways to escape a ceiling you will hit again in eight months is wasted effort.
The event: the acquisition
On August 4, 2026, Airtable announced it had agreed to be acquired by Bending Spoons. That is a fact, and here is what it is not: it is not a prediction about what happens to the product, the pricing, or your data. Nobody outside those two companies knows, and any article claiming to is selling something.
What an ownership change is, reliably, is the moment sensible teams audit their dependencies. The useful response is not panic-migration — it is checking, this week rather than eventually, that your data is portable in practice: run a full export, confirm the relationships survive it, and know what a move would actually take. If the audit comes back "we could leave in a weekend if we ever had to", you have converted anxiety into a contingency plan and you can stop reading news coverage. If it comes back "we are more locked in than we thought", that is worth knowing regardless of what the new owner does.
What to check on any alternative
Whichever wall you hit, evaluate candidates on these, in this order:
- Relation depth. Test with your real model, not a demo. This is the one that cannot be worked around.
- Permissions granularity. Row-level, field-level, and what tier each sits on.
- Export fidelity. Can you get your data out with relationships intact, or does export flatten to CSVs where links become names again? Test this during the trial, not after. Data you cannot extract with structure intact is data you do not fully own.
- API and rate limits. If anything downstream reads your data, the rate limit is a real constraint. Ask for the number.
- Audit and recovery. Is history per-field? Is deletion recoverable? Soft delete with a recycle bin is the difference between an incident and a catastrophe.
- Cost at 3× your current size, with your realistic seat mix.
The migration itself
If you do move, the data is the easy part. The work is elsewhere:
- Automations have to be rebuilt. They rarely port, and this is usually the largest chunk of the effort. Inventory them before you commit to a timeline.
- Integrations have to be repointed. Every webhook, every script, every connected tool.
- Views and filters must be recreated, and this is a good opportunity to delete the ones nobody uses.
- People need retraining, which is small but real.
A practical sequence: move one workflow first, run both in parallel for a fortnight, and only then move the rest. Big-bang migrations in this category go wrong in the automations, and you want to discover that on one workflow rather than all of them.
The parallel-run period is also the thing to demand tooling for. An importer that runs once forces the cutover to be a moment; one that can re-run on a schedule — new and changed records flowing across while both tools stay live — turns the migration into a period, which is the only shape that survives contact with a busy team. (This is how RowFold's Airtable import works: full-fidelity import including linked records and attachments, then an optional hourly or daily one-way mirror while you move.)
Where RowFold fits
We built RowFold specifically around walls 2 and 3, so it is only fair to be direct about it.
Relations traverse multiple hops — lookups and rollups follow a path across several tables rather than stopping at one link — because that was the constraint we kept running into ourselves. Permissions go from folder down to field level — a whole folder can be granted in one action, or hidden so completely that its name disappears. There is a full audit trail and soft delete, and the REST API returns relationships rather than flattened text.
It is a younger product than Airtable, with a smaller template library and a smaller integration ecosystem. If you need a specific third-party connector that already exists elsewhere, that is a genuine reason to choose something else, and we would rather you knew that before a trial than after one.
The honest recommendation
If you are hitting wall 1 (cost), first check whether your seat mix can be restructured. Often it can.
If you are hitting wall 2 or 3 (depth, permissions), those are structural and worth switching for — but test them with your real model during a trial.
If you are hitting wall 4, do not switch sideways. You need engineering.
And if Airtable is working for you, staying is still a defensible answer — "it works" beats "it is 15% better" almost every time. The acquisition does not change that arithmetic; it changes the homework. Staying comfortably now requires knowing your exit is real: a tested export, relationships intact, and an honest estimate of what a move would take. Do that audit once and staying becomes a decision instead of a default.