Flexible structure, or governed structure
Airtable is built for shaping structured, collaborative data quickly, and it is very good at that. Bondi is built for the point after that: a dedicated database, and on Pro, permissions that follow the record, external portals, a reviewed publish step, and machine identities that obey the same policy. The real question is whether you still need the structure to be easy to change, or need it to be hard to change by accident.
Base boundaries become question boundaries
Base boundaries get decided early, when the operation is small, and they quietly become the boundaries of what you can ask. By the time one customer's records are spread across three bases, the sync between them is doing work that a foreign key would have done for free, and the answer to any cross-base question is a manual export.
Signals to look for
None of these is decisive on its own. Three or more together usually is.
-
Base boundaries no longer match business boundaries
The customer exists in two bases because the operation grew that way, and a sync keeps them roughly in agreement. "Roughly" is the part that costs.
-
The external workflow outgrows one base
Airtable Portals give clients and suppliers their own sign-in to shared interfaces, one portal per base. When their step spans several bases or needs rules of its own, the portal inherits the base boundary.
-
Visibility differs by record, not by field
The rule you need is "this client's records", not "this column". Airtable interfaces can filter records to the current user, page by page — but the rule then lives in each interface, not in the data, and anyone with base access sees every record.
-
Automation ownership is per base
Each base has its own automations and its own owner, and nothing has a view across all of them or a shared failure queue.
-
Change control stops at the edge of one base
On Business and Enterprise Scale, Airtable's App sandbox lets a builder stage structural changes to a base and publish them selectively. A change that spans several bases and the syncs between them still has no single review step, and on other plans the base is edited live.
Two different design centers
Airtable optimizes for structure you can change in seconds. Bondi optimizes for structure that holds under a production operation. Both are deliberate.
| What you are deciding | Airtable Built around reshapeable bases | Bondi Built around a database you own |
|---|---|---|
| The unit the system revolves around | A record in a base you can reshape at any time | A row in a schema, with relationships and types enforced by the database |
| How structure is expressed | Tables, fields and links inside a base | Tables, columns, foreign keys and domain types in PostgreSQL |
| How access is scoped | Base roles, field and table editing permissions, and record filters set per interface page | Role, screen and action on Standard; record and field on Pro, with custom roles and Service Accounts |
| How external people participate | Invited collaborators, or a paid Portals add-on with its own sign-in, one portal per base | External Portals on Pro, with no Portal-count or external-user seat limit |
| How automation is expressed | Automations configured per base, documented by Airtable | Workflows across the whole system, metered as max(1, ceil(billable Actions / 20)) |
| How a change reaches production | Edited live, or staged in an App sandbox and selectively published (Business and Enterprise Scale) | Published from Development to Production, with version history and restore (Pro) |
| Where the data sits | Inside the product, reachable through its API | A dedicated PostgreSQL database per environment, with import, export and a full SQL export on Pro |
| Where it stops | When base boundaries stop matching business boundaries | When the structure still needs to change daily and nobody will own it |
A comparison of design centers, not a feature scorecard. Statements about Airtable are limited to its own published documentation and the date noted in Sources.
How to evaluate it
Five steps, in order. Each one produces something you can put in front of other people rather than an opinion you have to defend.
- 01
Test visibility separately from editing
Check whether your rule is about who may edit a field, or about which records exist for a person at all. They are genuinely different problems, and only one of them is about editing — the matrix above shows which axis each product is built on.
- 02
Count the cross-base syncs
Every one is a relationship the data model could not express. The count is a direct measure of how far the structure has drifted from the business.
- 03
Map the automation allowance and the record limit separately
Airtable meters automation runs per workspace and records per base, so they are two different budgets with two different blast radii. Model your busiest month against both, not your average one — a limit is only ever felt at the peak.
- 04
Write down what a controlled change would look like
Who reviews it, where it is tested, and how it is undone. If the honest answer is "we change it live and tell people", decide deliberately whether that is acceptable for this system.
- 05
Check what leaves with your data
Not only the rows: the relationships, the computed fields, and the automation logic. Exporting records is common; exporting the model is the part to verify.
Where this leaves Bondi
Where Bondi fits
Bondi Pro is the honest comparison point: record- and field-level permissions, Portals with no external-user seat charge, Service Accounts, and Development → Production publishing with version history and version restore — on a dedicated PostgreSQL database an owner can export in full as SQL.
- Record- and field-level permissions, custom roles and Service Accounts on Pro
- External Portals on Pro, with no Portal-count or external-user seat limit
- The 30-day trial runs Pro capabilities on Standard quotas for up to 3 users, with no card
The other half of the answer
When Bondi is the wrong answer
- The structure is still being discovered and needs to change several times a week
- A base and a shared interface genuinely cover the whole workflow
- You want a tool anyone can reshape without a review step — that is a legitimate preference, and Bondi's publish step is the opposite of it
If one of these describes you, the honest recommendation is somewhere else. Nothing on this page is improved by pretending otherwise.
Common questions
Does Airtable lack permissions?
No. Airtable documents field- and table-level editing permissions, and its interfaces can filter records to the current user. The question is where your rule has to hold: "this column is read-only" and "this client's records do not exist for this person" are different requirements, and an interface filter does not restrict someone with base access.
Can we import our Airtable data?
Yes. Bondi supports data import and export, and a staged migration lets Airtable stay in place while one workflow at a time is validated in Bondi.
What do we give up?
Immediacy. Changing a Bondi system means editing in Development and publishing a reviewed change set on Pro. That is slower than editing a base, deliberately — it is the same property that stops an accidental change reaching a live operation.
Do we need Pro?
For record- and field-level permissions, Portals, MCP, Service Accounts and Development → Production publishing, yes. The 30-day trial runs Pro capabilities on Standard quotas for up to 3 users, with no card, so those capabilities can be tested before the decision.
Sources
- Airtable — Field and table editing permissions checked 2026-08-03
- Airtable — Interface Designer permissions checked 2026-09-25
- Airtable — App sandbox checked 2026-09-25
- Airtable — Using Airtable Portals for external collaborators checked 2026-09-25
- Airtable — Getting started with automations checked 2026-08-21
- Airtable — Plans and limits checked 2026-08-21
Claims about third-party products are limited to what these documents state on the date shown. Where a document is silent, this guide describes the product's design center rather than asserting a limit.