First, the thing that sent you here
You do not have to take a competitor's word for it. Airtable's own technical requirements page says it in one sentence: “Offline access to Airtable is not supported, however, there are several options available for exporting your data to access it offline.”
The exports it goes on to describe are CSV per table, with attachments fetched separately, or a periodic pull through the API. Both are backups. Neither is a base you can open on a train and add a row to.
This is not an oversight, and Airtable have been fairly straight about why: a shared relational base with rich field types is genuinely hard to merge after two people have edited it apart. That is a real engineering problem, and it is the whole subject of the rest of this page.
What “local-first” means — and what it does not
The term is not marketing language, it is a term of art with a paper behind it. It comes from Local-first software: you own your data, in spite of the cloud, by Martin Kleppmann, Adam Wiggins, Peter van Hardenberg and Mark McGranaghan, published by Ink & Switch and presented at Onward! in 2019. Their argument is that in a cloud app the server holds the real document and you hold a view of it, and that this is backwards: the copy on your own machine should be the primary one, with the network as the thing that reconciles copies afterwards.
The paper sets out seven ideals, and they are a better checklist than anything a vendor will give you: fast (no network round-trip to do a thing), multi-device, offline, collaboration, longevity (it still opens if the vendor goes away), privacy, and user control. Note that “offline” is one of seven — a tool can have offline mode and miss the other six.
Practically, that is the difference between two sentences:
- Offline mode: the app is normally online, and can survive a while without a connection. Offline is an exception it handles.
- Local-first: the app is normally local, and syncs when it can. There is no exception to handle, because there was no dependency to lose.
Almost every tool in this category will tell you it is one of these. Very few will tell you which.
Five questions that tell you which one you are looking at
These are deliberately answerable — you can settle every one of them yourself in a few minutes, without trusting anybody's landing page, including this one.
1. Turn off the network and create a record. Then restart the app.
Not read a record — create one, then quit and relaunch while still offline. A lot of “offline support” is a memory cache with a queue behind it, and the difference shows the moment the process dies.
2. How much of a large table comes with you?
Ask for the number, not the yes. A tool can truthfully answer “yes, databases work offline” while bringing 50 of your 900 rows. If the answer is “all of it”, ask where it is stored and how big it gets.
3. What happens when the same row is edited on two devices?
This is the question the whole field is actually about. There are honest answers — last write wins, a conflict copy, a CRDT that merges per field — and there is the dishonest one, which is silence. Any tool that genuinely syncs has thought about this and can tell you which it does.
4. Where does the file live, and can you open it without the app?
“Your data is yours” means very little until you can point at it. A path you can back up, copy to another machine, or read with something else is a different promise from an export button, which is a favour the vendor can withdraw.
5. If the company disappears tomorrow, does the app still open?
For a genuinely local-first tool the answer is yes, minus sync. If the answer is no, what you have is a cloud app with a cache — which may still be the right tool for you, but you should know which one you bought.
The trade-offs nobody advertises
Local-first is not free, and a page that only lists its advantages is selling something. The real costs:
- Permissions get harder. If the data is on the device, “this column is hidden from contractors” is a much weaker statement than it is on a server that simply never sends the column.
- Storage is finite. A base with thousands of attachments cannot be entirely on a phone. Something has to be partial, and you want to know what.
- Merges are visible. A server can pretend conflicts do not exist by refusing the second write. A local-first app has to show you something.
- Real-time collaboration is the hard case. Several people typing in one table at once is what the cloud architecture is genuinely good at.
If your work is a shared operational base that ten people are in all day, Airtable's design is answering your problem, not dodging it. If your work is your own data, on your own devices, and the network is the least reliable part of your day, the trade goes the other way.
Where Platform sits
Platform is the second answer: databases with the field and view types you would expect, plus workflows, a knowledge graph and charts, in one native app for iPhone, iPad and Mac, with the records on the device and sync running behind them.
It is not released — it is not on the App Store, you cannot install it today, and it is deliberately not on the shortlist above for that reason. The waitlist is the honest version of a call to action here: it tells you when there is something to actually try, and nothing before then.
In the meantime, the five questions work on every tool you evaluate, including this one when it ships. Ask them.