Which fits your Airtable situation: Airtable or self-hosted Baserow?
Stay on Airtable if the bases are working, the team does not have a server to run, and the data location requirement is already met by Airtable's own terms. Move toward self-hosted Baserow when a renewal or per-seat price increase, a data residency rule, or lock-in makes it hard to keep records, attachments and access rules on your own servers. Airtable's Europe and Australia data residency only comes with Enterprise Scale, and base and workspace metadata, user and authentication data stay in US data centers regardless of region, so a residency requirement needs a careful read of your own obligations before you accept that arrangement.
Baserow fits when you want the grid views, record data and attachments inside your own infrastructure and can accept that you now operate the platform. Its core is MIT licensed, but Premium, Advanced and Enterprise features sit outside that grant, and an instance can run only one paid license type. Single sign-on is available on Advanced and Enterprise, so an organization that needs SSO for its users should price that license before assuming the community edition covers it. Confirm with Baserow which features your bases depend on, such as role-based permissions and audit logs, since these are listed against Advanced rather than the free tier.
The decision turns on three checks: where your data must physically and legally sit, which paid Baserow features your access model needs, and whether your team can run, patch and back up a Baserow server with an external PostgreSQL database. Start with the data location check, because it decides whether self-hosting is necessary at all. If that check points toward self-hosting, confirm the license tier and your operations capacity before you plan a migration.
Which option fits each scenario
This table matches common Airtable situations to the option that usually fits better, with the reason tied to supplied facts. Read each row as a starting point, then confirm licensing, residency and staffing against your own requirements before deciding.
| Scenario | Better fit | Reason |
|---|---|---|
| Small team on Airtable's free tier | Baserow (Free or self-hosted community edition) | Airtable's Free plan caps each base at 1,000 records, while self-hosted Baserow's MIT-licensed core has no per-base record cap set by the vendor, so growth depends on your server. |
| Regulated team needing data in its own jurisdiction | Self-hosted Baserow in a chosen data center | Airtable's EU or Australia region is only on Enterprise Scale and metadata and user data stay in US data centers, while self-hosting keeps base data, metadata and accounts in one place you control. |
| Team needing single sign-on | Baserow Advanced or Enterprise, self-hosted | Baserow's SSO covering SAML, OAuth 2.0 providers and OpenID Connect requires an activated Advanced or Enterprise license, so budget for that license alongside hosting. |
| Team with no infrastructure staff | Airtable, or self-hosted Baserow only with a managed partner | Self-hosting adds servers, PostgreSQL, backups and upgrades, so confirm who will run them before choosing; an external operator or managed support is the practical path. |
| Heavy automation or formula use | Airtable for now, or evaluate Baserow after rebuilding | Baserow's importer does not carry over formula, lookup, rollup fields, automations or interfaces, so these must be rebuilt and tested before cutover. |
| Bases with many attachments and grid views | Baserow | The importer copies attachments, field types, relationships and grid views with filters and sorts from a public share link, one base at a time. |
| Need for a full base export as one file | Baserow or self-hosted alternative with direct database access | Airtable exports each table as its own CSV from a view, so a complete extract takes more steps than a self-hosted database dump. |
Where your records, attachments and accounts live
Airtable's regional options cover base data, but the platform keeps base and workspace metadata and user accounts in US data centers. A self-hosted Baserow instance moves all of those into the infrastructure you choose, so residency decisions become deployment decisions. The cards below cover what Airtable keeps, what self-hosting changes, and which license tier governs identity and audit.
Airtable's US metadata and accounts
Airtable's data residency documentation states that base and workspace metadata, along with user and authentication data, stay in US data centers regardless of the region you choose. A Europe or Australia region applies to base data only. Regional residency is limited to the Enterprise Scale plan, so a team on Team or Business cannot select it. Ask Airtable in writing which data categories each region covers before you write a residency requirement into a policy.
Single container hosting model
The baserow/baserow Docker image runs all Baserow services in one container, with an internal PostgreSQL and Redis by default. This is the fastest way to evaluate Baserow and keeps records, attachments and accounts on a host you control. Baserow highly recommends an external PostgreSQL for production, so plan a separate database instance with its own backups, encryption and access controls before go-live.
Compose and Kubernetes for scale
Baserow documents Docker Compose with separate backend and web-frontend images, and Kubernetes with Helm, for horizontally scaled deployments. Both place the database, file storage and application tiers under your network controls, so you decide where attachments are written and who can reach the backend. Confirm the storage backend for attachments with your platform team, since it determines where file contents sit and how they are backed up.
Single sign-on requires a license
Baserow single sign-on covering SAML, OAuth 2.0 providers and generic OpenID Connect is available on the Advanced and Enterprise plans with an activated license. On a free self-hosted instance, users sign in with Baserow accounts, so identity lifecycle, MFA and offboarding must be handled inside Baserow. Confirm which identity provider you will federate with before you choose a license type, because an instance can run only one license type.
Audit logs follow the tier
Baserow's pricing page lists audit logs among the Advanced features, so the tier you choose determines whether administrators can review who changed which records and permissions. Compare that with the audit needs in your control framework before deciding. Where your auditors expect centralized log retention, plan to export or forward logs to your own SIEM and confirm the export format with the vendor.
Licensing scope and data location
Self-hosted Baserow licenses are tied to your instance, and the Premium, Advanced and Enterprise terms are documented separately from the MIT-licensed core. Record the license type, the instance location and the owner of each database backup in one register. This keeps the residency answer and the license answer consistent when auditors or procurement ask where the data physically resides.
Which Baserow features need a paid license when self-hosted
Baserow's core is MIT-licensed, and premium and enterprise features sit outside that grant. Under the open core model, all non-premium and non-enterprise features can be used for commercial and private purposes without a fee, so a team can self-host the database, views, API and most automations at no license cost. The paid tiers add capabilities on top of that core, and they are the part you need to map to your own requirements before the first deployment. Do not assume that a feature visible in the interface is free to run on your server. Check each feature you depend on, including the application builder pieces you plan to use for portals or review pages.
Self-hosted Baserow offers three paid license types: Premium, where seats are assigned manually to named users; Advanced, which grants paid access to users on the instance; and Enterprise, priced through sales. An instance can run only one license type at a time, so a team cannot mix Premium seats with Advanced access on the same installation. Single sign-on is the clearest example of a gated control. SAML, OAuth 2.0 providers such as Google, GitHub and GitLab, and generic OpenID Connect are available on the Advanced and Enterprise plans, and only once the license is activated on the instance. If your identity provider rules require SSO for every account, Premium alone will not meet that requirement.
Before you choose a tier, confirm the feature matrix against Baserow's current self-hosted license documentation, not against the cloud pricing page, because the two do not map one to one. Ask the vendor in writing which features each license type covers in the version you will run, how seats are counted and reassigned, and what happens to user access if a license lapses. Record the answers in your design file. Test SSO and role-based access in a staging instance with the license activated before cutover, since these controls are often the reason an audit or security review asks for a paid tier.
How self-hosted Baserow runs in your environment
The quickest route is the baserow/baserow Docker image, which runs all Baserow services in one container with an internal PostgreSQL and Redis by default. This suits evaluation, a small team trial or a proof of the Airtable import on non-production data. Operating work stays light, but the database, cache and application share one host, and the internal database is not what Baserow recommends for production.
- Setup: Start the container with persistent volumes so data survives restarts, and place it behind your TLS terminator.
- Backups: Schedule backups of the data volume and test a restore before relying on the pilot for anything real.
- Upgrades: Pin the image tag, read the release notes for each version and take a snapshot before changing it.
- Access: Restrict network access to the pilot, since single sign-on and role-based controls are paid features on the license tiers.
- Exit path: Plan to move to an external PostgreSQL when the pilot becomes a shared system.
Confirm with Baserow which resources a single container needs for your row counts and user numbers before assuming a host size.
Baserow highly recommends an external PostgreSQL for production deployments, so the database can be sized, backed up and patched separately from the application. Your database team or managed database service usually takes on this work, and the Baserow instance becomes stateless enough to rebuild. This model fits most regulated teams that need clear ownership of backups and restores.
- Database ownership: Assign a named owner for PostgreSQL, including version support, patching and point-in-time recovery.
- Connection settings: Point the Baserow configuration at the external database and confirm the connection under TLS where your policy requires it.
- Redis: Decide whether Redis runs inside the container or as a separate service, and document the choice.
- File storage: Confirm where uploaded attachments are stored, since they must be backed up alongside the database.
- Monitoring: Alert on disk growth, failed background jobs and failed backups.
Ask Baserow to confirm the PostgreSQL version, storage and memory guidance for your expected record volume.
For larger user populations, Baserow documents Docker Compose with separate backend and web-frontend images, and Kubernetes with Helm, for horizontally scaled deployments. This model separates the web and API tiers so each can run more replicas behind a load balancer. It adds moving parts, so it is usually justified by measured load rather than by headcount alone.
- Orchestration: Choose Docker Compose for a small number of hosts or Helm for a Kubernetes cluster your team already runs.
- Shared services: Keep PostgreSQL and any cache external and highly available, since replicas depend on them.
- Configuration: Keep environment settings and secrets in your secret store and version the Helm values or Compose files.
- Upgrades: Roll out backend and frontend versions in a tested order, with a rollback plan.
- Capacity: Load-test with representative bases, views and API traffic before go-live.
Confirm sizing, replica counts and supported topologies with Baserow in writing before you commit to an architecture.
What Airtable and self-hosted Baserow cost to own
Airtable charges per user on published plans, with Enterprise Scale priced on request. Self-hosted Baserow has a free community edition, but the paid license tier, hosting, database operations and administration still carry cost. The cards below separate what is paid for once from what recurs, so a written quote can be compared line by line.
Airtable per-seat subscription
Airtable's Team and Business plans are billed per user per month, with the Enterprise Scale plan on custom pricing. Seat count is the main driver, so the cost grows with every editor and reviewer who needs access. Check which users need edit rights, which only need views, and whether external collaborators count toward seats. Confirm the current prices on Airtable's pricing page, since they change over time.
Baserow license tier
The Baserow community edition is free under the MIT License, but Premium, Advanced and Enterprise license types are paid. Single sign-on, role-based permissions and audit logs sit in the paid tiers, so teams that need them must budget for a license. An instance uses only one license type, so confirm which features your rules require before you choose a tier. Ask the vendor for the current seat pricing and what changes when users are added.
Record and API caps
Airtable limits records per base by plan and caps API calls per workspace per month, so growth can force an upgrade even when seat count stays flat. Self-hosted Baserow has no per-base record cap of this kind, but its practical limits come from the servers, database and storage you provision. Model expected record and attachment volume for three to five years, then size the database and file storage to match.
Hosting and PostgreSQL operations
Baserow's Docker image bundles PostgreSQL and Redis for testing, but Baserow highly recommends an external PostgreSQL for production. Your team or a partner then pays for the database servers, high availability, patching, connection management and monitoring. Ask whether the quote covers managed or self-run PostgreSQL, the cloud or data center where it runs, and who holds the on-call duty.
Backups, upgrades and administration
With Airtable, the vendor runs the platform, but you still manage access reviews and exports. Self-hosting moves backups, restore tests, version upgrades and security patching to your side. Recurring work includes testing restores of both the database and attachment storage, and planning upgrades across the Baserow releases your team adopts. Ask the quote to name who performs each task, how often, and what a restore test covers.
Migration and rebuild effort
Baserow's importer copies tables, records, attachments, relationships and grid views from a public share link, one base at a time. Formula, lookup, rollup and collaborator fields, automations, interfaces, comments and revision history do not come across, so they must be rebuilt and tested. The rebuild is usually the largest one-time cost. Ask the quote to list each base, the fields and automations to rebuild, and the validation steps for each.
What moving bases from Airtable to Baserow involves
The sequence turns each Airtable base into a tested, permissioned Baserow database and retires the original only after its logic, access and integrations have been checked.
Inventory bases, views and automations
Before any import, list every base in scope, its tables, the views each team relies on, and every automation, interface, formula, lookup and rollup field. Note which integrations and API clients read each base and which people hold access. Record the output as a migration register with one row per base. Done means the owner of each base has confirmed the list, and every field type is marked as either carried by the importer or needing a rebuild. Because the importer skips formula, lookup, rollup and collaborator fields, automations and interfaces, this register shows how much logic must be rebuilt by hand.
Prepare the self-hosted Baserow instance
Install Baserow in your own infrastructure, using the Docker image for a single host or Docker Compose or Helm for a horizontally scaled deployment. Baserow recommends an external PostgreSQL database for production, so provision that database and backups before importing anything. Decide whether the instance runs on the free community edition or needs a paid license for single sign-on or role-based permissions. Done means a test workspace is reachable over HTTPS, backups have restored successfully once, and the team has agreed who administers the instance.
Run the importer one base at a time
For each base, make a public share link in Airtable and paste it into Baserow's Airtable importer. The importer copies tables, records, attachments, field types, relationships and grid views with their filters and sorts. It works one base at a time, so repeat the process for each base in the register. Note the import identifier or table names for each run. Done means each imported base has been opened in Baserow and its record counts match Airtable for every table.
Check attachments, relationships and grid views
Compare each imported table with its Airtable source. Open a sample of attachments to confirm files arrived and display correctly. Follow linked record fields in both directions to confirm relationships still point to the right rows. Compare each grid view's filters and sorts against Airtable. Because the importer does not bring across comments or revision history, record in the register anything that people relied on from those sources. Done means a signed-off checklist exists for every table, with any mismatches logged as defects to fix before cutover.
Rebuild formula, lookup, rollup and automation logic
Recreate each Airtable formula, lookup and rollup field as a Baserow formula or as a stored value that a Baserow automation maintains, since these fields are not carried across. Rebuild each Airtable Automation as a Baserow automation or as a webhook to a workflow tool, and rebuild each interface as a Baserow application builder page. Test each trigger with sample records, checking that the output matches the original Airtable result. The effort here depends on how much logic lives in Airtable: a base with few formulas needs little work, while a base that drives reporting or approvals can need significant rebuilding. Done means each rebuilt rule has a documented test case and a matching output.
Test permissions and integrations
Recreate workspace and table permissions in Baserow so each group sees only the tables and rows it needed in Airtable, and test them with a test account for each role, including any external users. Repoint every integration, API client and script from Airtable's API to the Baserow REST API, using tokens issued from the new instance, and verify each one writes and reads correctly. If single sign-on is required, confirm it works against the identity provider your organization uses, since SSO is available only on the Advanced and Enterprise plans with an activated license. Done means each role and integration has a signed-off test result.
Cut over and retire the old bases
Agree a cutover window with the owners of each base, freeze edits in Airtable, run a final import of any records changed since the earlier test, and repoint users and integrations to Baserow. Keep the Airtable bases read-only for an agreed period so teams can check for gaps. Export a final copy of each base's data as CSV per table, since Airtable does not export a whole base as a single file, and store it under your retention policy. Then remove Airtable access and cancel the plan once the owners sign off. Done means each base has a written owner sign-off, an archived export, and a closed Airtable account or plan.
Where Baserow falls short of Airtable and what to verify
The gaps between Airtable and self-hosted Baserow matter most in three places: interfaces, automations and formulas. Baserow's Airtable importer copies tables, records, attachments, field types, relationships and grid views with filters and sorts, but it does not carry over formula, lookup, rollup or collaborator fields, automations, interfaces, comments or revision history. Every base that depends on those pieces needs rebuilding, and the work grows with how much logic lives in interfaces and automations rather than in plain tables. A base with heavy formula and lookup logic should be the first thing you inventory, because the rebuild effort will concentrate there.
The gaps also depend on who runs the system. Self-hosted Baserow runs on your own servers, so your team owns the host, the database, backups, TLS, upgrades and the license key if you buy a paid tier. The Docker image runs all services in one container with an internal PostgreSQL and Redis by default, while Baserow highly recommends an external PostgreSQL for production. If nobody on your staff can operate PostgreSQL and a container platform, that is a cost to price in before choosing this route. Plan for an external database, a tested restore procedure and a dated upgrade calendar from the start.
Before committing, run a pilot against a copy of one real base and check these items: formula coverage, with each formula rewritten and tested against known outputs; automation triggers, with each trigger mapped to a Baserow automation or an external workflow; attachment migration, confirming files and links arrive intact through the public share link import; API limits, measured against the integrations that call Airtable today; and the SSO tier, since Baserow single sign-on is available on the Advanced and Enterprise plans with an activated license. Ask Baserow in writing which license type fits your user count, because an instance can use only one license type. Confirm each item in your own environment rather than relying on this summary.
Questions buyers ask before switching from Airtable to Baserow
What does switching from Airtable to self-hosted Baserow cost?
The software itself can be free: Baserow is open core, and its non-premium, non-enterprise features are MIT licensed. The cost comes from the components around it. You pay for the servers or cloud accounts that run Baserow and an external PostgreSQL database, for storage of attachments, for backups, and for the people who operate and patch the instance. Paid self-hosted licenses are optional and are needed only for features such as single sign-on. One-time costs include the migration, rebuilding automations and interfaces, and user training. Recurring costs include hosting, administration and upgrades. Ask any quote to split these components, and compare the total with your current Airtable seats across Team, Business or Enterprise Scale, using your own user count and record volume.
How long does an Airtable to Baserow migration take?
No duration is supplied for this migration, so treat any figure you hear with caution. The timing depends on the number of bases, the size of their attachments, how many formula, lookup, rollup and automation fields must be rebuilt, the number of integrations pointing at Airtable, and how much testing your business owners require before cutover. Baserow's importer works one base at a time from a public share link, so a portfolio of many bases takes longer than one or two. A pilot with your most important base is the most reliable way to measure your own timeline before you commit to a schedule.
Can our team migrate from Airtable to Baserow without outside help?
Yes, a small team with a clear inventory can run a pilot alone, especially for simple bases made of plain tables, text fields and grid views. The difficulty rises with the number of dependencies. Formula, lookup and rollup fields, collaborator fields, automations, interfaces, comments and revision history do not come across in the importer, so each must be rebuilt and checked by hand. Teams that own a production system often choose a fixed-scope engagement for the rebuild, the hosting, the identity setup and the backup plan, while keeping data owners in charge of acceptance testing. Be realistic about who will operate the instance after go-live.
What skills does our staff need to run a self-hosted Baserow instance?
Baserow's documentation describes Docker and Docker Compose deployments, with separate backend and web-frontend images, and a Kubernetes deployment with Helm for horizontally scaled setups. Your operations staff need container administration, PostgreSQL basics, reverse proxy and TLS configuration, backup and restore practice, and a process for upgrades. Application owners need to understand Baserow's table, view, field and permission model, and power users need to rebuild their own formulas and automations. Confirm the exact configuration keys and supported deployment methods against the current Baserow installation documentation for your version before you plan staffing.
Does the Baserow Airtable importer bring over formulas and automations?
No. Baserow's Airtable importer copies tables, records, attachments, field types, relationships and grid views with their filters and sorts, from a public share link, one base at a time. It does not carry over formula, lookup or rollup fields, collaborator fields, automations, interfaces, comments or revision history. Plan to recreate those items in Baserow, using its formula support, automations and application builder where they fit. Build an inventory of every Airtable formula and automation before the pilot, and test each rebuilt item against the results in Airtable, not just against the import log.
Does single sign-on in self-hosted Baserow require a paid license?
Yes. Baserow single sign-on, covering SAML, OAuth 2.0 providers such as Google, GitHub and GitLab, and generic OpenID Connect, is available on the Advanced and Enterprise license plans with an activated license. The free open-source edition does not include it. Baserow documents three paid self-hosted license types: Premium, with seats assigned manually to users, Advanced, which grants paid access to users on the instance, and Enterprise, priced through sales. An instance can use only one license type. Confirm current license terms with Baserow before budgeting, since licensing rules can change between releases.
How would an implementation partner scope a fixed-scope Airtable to Baserow engagement?
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted platforms in your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. A typical scope for this migration would list the bases in play, the hosting target, identity and SSO setup, the rebuild of formulas and automations, data validation, cutover and backup, and handover documentation. Ongoing support, upgrades and continuous testing are available as retainers. Ask any provider to name the deliverables, acceptance criteria and exclusions in writing.
Will Baserow keep our Airtable data in our own jurisdiction?
A self-hosted Baserow instance keeps base data, metadata and user accounts on the servers you choose, so the jurisdiction is the one you select for your data center or cloud region. This contrasts with Airtable, where data residency outside the US is available only on Enterprise Scale and base and workspace metadata, along with user and authentication data, stay in US data centers regardless of region. Confirm your own legal and contractual requirements with your counsel, and document where backups and attachment storage are located as well.
How DeployOpen helps evaluate and migrate to self-hosted Baserow
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Airtable vs Baserow, the work starts with a written scope that tests which Airtable bases can move cleanly and which features must be rebuilt.
How we scope
- We inventory the Airtable bases, tables, views and attachments you want to move, one base at a time.
- We list which fields, automations and interfaces will not carry over and agree how each is rebuilt.
- We confirm which Baserow license type, if any, your single sign-on and user model require before work starts.
How we build
- We deploy Baserow in your environment, with an external PostgreSQL database for production use.
- We run test imports from a public share link and check records, attachments, relationships and grid views.
- We rebuild required automations and application pages, then test permissions for internal and external users.
How we hand over
- We document the deployment, configuration, backup procedure, user access model and rebuilt base logic.
- We provide a cutover plan with a rollback path and a checklist for confirming record counts and attachments.
- We walk your administrators through daily operation, upgrades and license administration before closing the engagement.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, version upgrades and continuous testing are available as a retainer after handover.
- We provide a written quote based on your scope, so you can compare it with your current Airtable cost.
