Which self-hosted alternative fits a base that outgrew Airtable's record caps
If a base is approaching or past Airtable's caps of 1,000 records per base on Free, 50,000 on Team or 125,000 on self-serve Business, the question is no longer whether a tool can store the data but whether your own servers can serve it well. Baserow, Grist and Teable can all hold larger record sets on infrastructure you control, so the practical ceiling is set by your sizing and your database choice. Baserow is MIT-licensed for its non-premium features, which makes it the most direct option for a team that wants a Postgres-backed table system with an importer that handles Airtable bases.
Grist and Teable differ in ways that matter for large bases. Grist keeps each document in SQLite and its open-source core is Apache 2.0, but single sign-on over OIDC or SAML needs an activation key in the full edition, so plan for that cost if your identity provider is central to access rules. Teable's Community Edition is AGPL-3.0 and runs on PostgreSQL, so its data is directly queryable, but its admin panel is listed for self-hosted Business and AI features need a license key. Confirm with each vendor which features your record volume depends on before you size anything.
Before committing, test the largest table you have with a copy of the real data. Load it into a staging instance sized like your planned production server, measure view load times, filtered searches and API responses, and confirm that the database backend and attachment storage meet your targets. Baserow's Docker documentation highly recommends an external PostgreSQL for production, which is a cost to budget for alongside hosting and administration. Ask each vendor, or your implementation partner, to state the record counts and attachment volumes their tested configurations have handled, since no such figure is given here.
What a record-heavy base requires from a replacement
A base that outgrows Airtable's per-base caps needs more than a larger number. The requirements below cover how many records the replacement must hold, where attachments live, how the data can be backed up and queried, and who can sign in.
Record volume beyond the plan cap
Airtable caps records per base at 1,000 on Free, 50,000 on Team and 125,000 on self-serve Business. A self-hosted replacement has no such per-base cap, so the practical limit becomes your database and server capacity. Check whether the chosen tool's cloud tiers differ from self-hosting, since Teable Cloud lists row limits per space. Ask the vendor for tested row counts on your largest table and on the views your team uses daily.
Attachment storage kept in-house
Airtable attachments are stored on Airtable's infrastructure, so a large file library stays outside your servers unless you export it. A self-hosted replacement must hold attachments on storage you control and back them up with the same discipline as records. Confirm how each tool stores uploaded files, where the storage path sits, and how file size and total volume affect disk planning before you migrate.
A database the team can back up and query
Airtable does not export a full base as a single file, and each table must be downloaded as its own CSV from a view. A replacement should give you a database you can back up whole and query directly. Baserow runs on PostgreSQL, Teable is built on PostgreSQL, and Grist documents are based on SQLite. Confirm the backup method for each option and test a restore before cutover.
Access control and single sign-on
Access rules and single sign-on may sit in a paid license tier rather than the community edition. Baserow single sign-on needs the Advanced or Enterprise plan with an activated license, and Grist connects to an identity provider over OIDC or SAML only with an activation key. Teable lists SSO on its Business cloud plan. List which access rules and identity connections your base depends on, then confirm their license tier before you commit.
Operating the instance
A self-hosted instance is your responsibility to upgrade, monitor and secure. Baserow's Docker image bundles all services with an internal PostgreSQL and Redis by default, and Baserow highly recommends an external PostgreSQL for production. Plan for upgrades between releases, such as the Baserow 2.4.1 release published on October 13, 2026. Ask the vendor or your partner who owns patching, restore testing and capacity reviews.
How Baserow, Grist and Teable compare on record volume and licensing
This table compares the three shortlisted platforms on license model, the database underneath, which self-hosted editions carry single sign-on, and how the Airtable import works. Read it as a checklist: the license and SSO rows decide what you pay for, while the database row decides how you query and size the data later.
| Capability | Baserow | Grist | Teable |
|---|---|---|---|
| License model for the core product | MIT for non-premium features, with premium and enterprise features excluded | Apache License 2.0 for grist-core | AGPL-3.0 for the Community Edition, with packages directory MIT licensed |
| Paid self-hosted tier | Premium, Advanced or Enterprise license, one type per instance | Full edition needs a paid plan after a 30-day trial, free for small organizations under the stated funding threshold | License key unlocks AI and advanced enterprise features; admin panel listed for self-hosted Business |
| Database underneath | PostgreSQL, with an internal PostgreSQL by default and external PostgreSQL recommended for production | SQLite-based documents, readable by any SQLite tool | PostgreSQL, with SQL query available in the interface |
| SSO in self-hosted editions | SAML, OAuth providers and generic OIDC on Advanced and Enterprise with an active license | Forwarded-header and getgrist.com sign-in on all editions; OIDC or SAML needs an activation key | SSO listed for Business on the cloud pricing page; confirm self-hosted SSO terms before you commit |
| Airtable import path | Importer from a public share link, one base at a time, with records, attachments and grid views | Import using a personal access token or an OAuth2 integration you register with Airtable | No built-in importer documented; bases move by CSV export and import, and you should confirm the current options |
| Formula, lookup and rollup fields on import | Not carried over; rebuild after import | Formulas rebuilt in Python or Excel-style functions | Confirm current coverage with the vendor before planning the move |
| Excluded from shortlist | NocoDB is excluded because its Sustainable Use License is not OSI-approved | NocoDB is excluded because its Sustainable Use License is not OSI-approved | NocoDB is excluded because its Sustainable Use License is not OSI-approved |
Where each platform's practical limit comes from
Baserow stores its data in PostgreSQL behind a Django backend and a Vue.js interface, so the practical ceiling for a large base is set mostly by the database server, the backend processes and the storage you provision. The Docker installation guide explains that the baserow/baserow image runs all services in one container with an internal PostgreSQL and Redis by default, which suits evaluation. For a production instance with growing record counts, Baserow highly recommends an external PostgreSQL, and that database becomes the first component to size.
- Database placement: Point the deployment at an external PostgreSQL instance with its own backups, monitoring and storage headroom, so database growth is managed separately from the application container.
- Service separation: Docker Compose runs separate backend and web-frontend images, so you can add backend capacity without changing the frontend tier.
- Horizontal scaling: Baserow documents Kubernetes with Helm for horizontally scaled deployments, which fits teams that already operate a cluster and can handle its storage class and ingress setup.
- Attachments and storage: Attachments add storage volume that grows separately from row count, so plan file storage and backup coverage alongside the database.
- License scope: Single sign-on and some administrative features need an activated Advanced or Enterprise license, so include licensing in the sizing conversation, not only hardware.
Ask Baserow for the row volumes it has tested on self-hosted instances and the database sizing it expects at your record count before you commit to a topology.
Grist keeps each document as a SQLite file, so the working data for one document lives in a single database file on the host. The gristlabs/grist image serves on port 8484 and writes to a /persist volume, so the storage layout, backup routine and disk performance of the host shape how large a document can practically grow. The self-hosting page covers the deployment options, and the limits of a single document are a question for the vendor.
- One file per document: Each document is a SQLite database, so a large document is a large file that must be copied, backed up and restored as a unit.
- Persistent volume: Mount /persist on storage with snapshot and backup coverage, because that volume holds all document data for the instance.
- Image choice: The gristlabs/grist-oss image contains only open-source code, which helps when you need a build whose contents you can describe to auditors.
- Sandboxing overhead: Optional gVisor sandboxing per document on Linux or with Docker adds isolation, and you should measure its effect on throughput during testing rather than assume it is negligible.
- Read access outside the app: Because SQLite is widely supported, reporting or recovery checks can run against the file, but run them on a copy so production locks are not affected.
Ask Grist for the tested document size, record volume per document and concurrent editor counts for self-hosted instances, and rehearse a restore of your largest document before go-live.
Teable is built on PostgreSQL, so the database engine and its operational tooling carry much of the load in a self-hosted instance. The Teable pricing page lists row limits per space for its hosted plans: 1,000 rows on Free, 250,000 on Pro and 1,000,000 on Business. Those caps are attached to the cloud service and do not carry over automatically to a self-hosted deployment, so confirm how the self-hosted build behaves at your row count.
- PostgreSQL underneath: The data sits in real PostgreSQL tables, so sizing, indexing, vacuuming and backup follow established PostgreSQL practice that your database team may already run.
- Cloud caps by plan: The hosted tiers differ in row allowance, so a base that fits Pro in the cloud may not map to the same limit in your own instance without a vendor statement.
- Two self-hosted scopes: Teable Cloud includes AI features and App Builder, while the standalone self-hosted deployment covers tables, collaboration, API and automation without AI features or App Builder.
- License key and admin panel: Paid self-hosted plans are activated with a license key on the same image, and the admin panel is described as part of self-hosted Business.
- Release pace: Teable publishes frequent releases, so schedule upgrade testing in a staging copy and read release notes for changes that affect storage or query behavior.
Ask Teable whether row limits apply to its self-hosted builds, which tier and license your row count requires, and what row volume it has tested on PostgreSQL.
What to size when records reach the hundreds of thousands
Once a base outgrows Airtable's caps, the constraint stops being a licensing tier and becomes your own infrastructure. The limit moves to the database, memory, storage I/O, attachment volume and API traffic. Baserow runs on PostgreSQL and Django, Teable is built on PostgreSQL, and Grist keeps each document in SQLite, so each platform's ceiling depends on how you size the database server, the application containers and the disks underneath them. Baserow's documentation highly recommends an external PostgreSQL for production, which is the first sizing decision to make. Ask each vendor which row volume it has validated in a production-like setup, and ask Grist which document sizes it has tested, since none of these answers should be inferred from a row count alone.
Raw row counts understate the load. Attachments, formula fields and linked records drive most of the work: attachments consume storage and bandwidth, formulas recalculate across dependent rows, and links force joins whenever a view or API call touches related tables. A base with 200,000 plain text rows and a base with 200,000 rows carrying attachments, lookups and rollups behave very differently (illustrative comparison). Inventory your base by field type, attachment total and the number of formula and link fields before choosing hardware. Grid views with many filters, sorts and grouped fields also need testing on realistic data, because a view that loads instantly at 5,000 rows can slow sharply at larger volumes. Build a copy of your own base, import it into a staging instance, and time your busiest views and API calls at the volume you expect in twelve months.
How to deploy Baserow for a large base inside your network
This sequence moves one large Airtable base into a self-hosted Baserow instance you run, with the sizing, licensing, import and verification checks needed before any users rely on it.
Size hosts and external PostgreSQL
Your infrastructure team sets the application hosts and a separate PostgreSQL server sized for the expected row count, attachment storage and concurrent users. Baserow's Docker installation documentation highly recommends an external PostgreSQL for production, so the bundled database inside the single container should not be the production store. Confirm host sizing with DeployOpen or your own capacity model against the row count of your largest base, since no fixed sizing figure is supplied here. The step is complete when the database and hosts respond from the network segment where Baserow will run and backups are configured for both.
Deploy Baserow behind your proxy and identity provider
Deploy the backend and web-frontend images with Docker Compose, or use the Helm chart for a horizontally scaled cluster. Place the instance behind your reverse proxy with TLS, and decide whether sign-in goes through local accounts or your identity provider. Single sign-on through SAML, OAuth 2.0 providers or generic OpenID Connect requires an activated Advanced or Enterprise license, so confirm this before choosing the login model. The step closes when a test administrator can sign in through the chosen path and the public URL resolves to the proxy.
Enable the license type your features need
Review the features you rely on, such as single sign-on, role-based permissions or audit logs, against Baserow's self-hosted license types. Premium assigns seats manually, Advanced grants paid access to users on the instance, and Enterprise is priced through sales. An instance can use only one license type, so choose before importing data. Ask Baserow for current terms, because the license pages define what each type includes. The step is complete when the license is activated and the admin panel shows the expected type.
Import one base from its public share link
In Airtable, create a public share link for the base, then run Baserow's Airtable importer against that link. The importer copies tables, records, attachments, field types, relationships and grid views with filters and sorts, one base at a time. Share links are the only input it accepts, so restrict the link's lifetime and revoke it after import. The step closes when the new Baserow database lists every table from the source base.
Verify record and attachment counts
Compare row counts for each table in Airtable and Baserow, then sample attachments by opening them in both systems and checking file names and sizes. Spot-check linked records in both directions, since relationships are imported but must be confirmed. Record any mismatch with the table and field name before moving on. The step is complete when counts match for every table and sampled attachments open correctly, or when each difference has a documented cause.
Rebuild formula, lookup and rollup fields
The importer does not carry formula, lookup, rollup or collaborator fields, automations, interfaces, comments or revision history. Recreate each formula, lookup and rollup in Baserow using the field definitions from the Airtable base, and check the results against values exported from Airtable for a sample of records. Document any collaborator fields you replace with user or text fields. The step is complete when recalculated values match the Airtable values for the sampled records and the rebuilt field list is recorded for reviewers.
Load-test views and API calls before cutover
Before users switch, run realistic filtered views and API requests against the imported table at full row count, using a load tool your team chooses. Measure response times on the heaviest grid views and the API endpoints your integrations call, then tune PostgreSQL indexes, worker counts or hosts based on what you observe. Baserow's API limits depend on the servers you run rather than a published cap, so the test defines your ceiling. The step closes when the agreed views and calls meet response targets your team set in advance, and the results are filed with the cutover plan.
Cut over and retire the Airtable base
Schedule the cutover with the owners of each table, freeze edits in Airtable, run a final incremental check of counts, and point integrations and users to the Baserow URL. Keep the Airtable base read-only for a period your business defines, and confirm that backups of the Baserow database and attachment storage run and restore successfully. The step is complete when users work in Baserow, integrations report success, and a documented restore test has passed.
What reviewers ask to see when records stay on your servers
Once Airtable records move onto your own servers, the reviewer's question changes from where the vendor stores data to what you can show about your own controls. The cards below list the artifacts auditors and internal risk teams usually request for a self-hosted Baserow, Grist or Teable deployment. DeployOpen prepares these artifacts with the client, but independent auditors and certification bodies issue any audit report or certification.
Architecture diagram and data flow
Reviewers want a diagram showing where the application server, PostgreSQL database, file storage for attachments, backups and reverse proxy sit, and which network zones each one crosses. For Baserow, the Docker image runs services in one container with an internal PostgreSQL and Redis by default, while Baserow highly recommends an external PostgreSQL for production. Ask which topology you are documenting and confirm it matches the deployed system.
Backup and restore test records
A backup schedule alone does not satisfy most reviewers. They ask for dated records showing that a restore was performed into a separate environment, which tables, attachments and user accounts came back, and how long the restore took. Because Airtable offers no whole-base export file, this evidence also proves that your own copy of the data is complete. Keep the restore logs with the database and attachment storage versions used.
Access review exports
Reviewers ask who can read, edit or administer each base and workspace, and when that was last checked. Export user lists, workspace roles and table-level permissions from the platform at a fixed date, then compare them with the identity provider. Baserow single sign-on on Advanced and Enterprise, and Grist's OIDC or SAML connection with an activation key, change where this evidence comes from, so confirm which identity source you are reviewing.
Upgrade change records
Each upgrade needs a change ticket that names the old and new version, the release notes reviewed, the test results and the rollback plan. Baserow published 2.4.0 on September 30, 2026 and 2.4.1 on October 13, 2026, and Grist published v1.7.20 on September 28, 2026 and v1.7.21 on October 9, 2026. Teable publishes releases frequently, so set a fixed review cadence and record which versions were skipped.
Load test results at target record volume
Because the self-hosted limit comes from your servers, reviewers ask for load test results at the record count you plan to hold, not at the vendor's default. Record the row count, concurrent users, attachment sizes, database resources and response times under typical grid, filter and API use. Limits such as the Airtable caps of 50,000 records on Team and 125,000 on self-serve Business have no equivalent in these platforms, so the test is the only evidence of capacity.
License documentation for paid features
If the deployment uses single sign-on, audit logs or other paid features, reviewers want the license type, the activation record and the seat or user count behind it. Baserow allows only one license type per instance, and Premium, Advanced and Enterprise are not interchangeable. Grist's full edition needs a paid plan for OIDC, SAML and audit log streaming, and Teable's paid self-hosted plans are activated with a license key. Keep the vendor license terms next to the activation records.
What moving an oversized base involves before cutover
Moving an oversized base is mostly a splitting and counting exercise, not a file copy. Airtable does not export a full base as a single file. Each table is downloaded as its own CSV from a view, so a base with many tables needs one export per table, and every view you export must be set up so it returns all rows and all fields you need. On a base near the 125,000 record cap for self-serve Business, that means checking each view's filters before you export, because a view that hides records will quietly shorten the extract. Plan this effort per table, and expect it to grow with the number of linked tables, since relationships must be recreated on the target after the data arrives.
Before you import, decide how the data will be split across target tables, and confirm that the target platform can hold each resulting table at the volume you expect. Baserow's Airtable importer works one base at a time from a public share link, so a base you split into several bases needs a plan for how links between them will be rebuilt. Reconcile counts at every step: record totals per table in Airtable against rows after import, and attachment counts separately, since attachments are the part most likely to fail or come across as broken references. Keep a dated reconciliation sheet as evidence for the cutover record.
Rebuild views and permissions for each group of users before anyone works in the new system. Recreate grid views with the same filters and sorts, then test that each role sees only the records it should. Re-link attachments and check that files open from their new locations. Ask the platform's implementer to confirm how row-level and field-level access behaves at high row counts, because permission checks that are fast on a small table can slow down on a large one. Run a parallel review period with a sample of records from every table, and set a rollback point you can return to if counts or permissions do not match.
Questions buyers ask before hiring help with a record-heavy migration
What drives the cost of moving a large Airtable base to a self-hosted platform?
The cost is driven mainly by scope and data shape, not by record count alone. Costs come from four components: the hosting infrastructure you run, the migration work itself, the rebuild of logic the importer does not carry over, and ongoing administration. Bases with many formula, lookup and rollup fields, automations, interfaces and linked attachments take longer to rebuild and verify than plain tables. Infrastructure costs recur monthly or annually, while migration and rebuild work is largely one-time. When you compare against Airtable's Team at $20 and Business at $45 per user per month billed annually, count per-seat fees across every user who needs access, and remember that self-hosted Baserow's community features and Grist's Community edition carry no per-seat license fee.
Can our own team migrate a record-heavy base without outside help?
Often yes, for a single base with simple fields and a small number of users, but the answer depends on your team's skills and the base's complexity. A capable administrator can deploy Baserow with Docker, run its Airtable importer from a public share link, and check record counts and attachments. Harder parts include rebuilding formulas in Grist's Python syntax or replacing automations, moving attachments with the correct field types, and designing a production PostgreSQL and backup setup. Ask yourself whether anyone on staff has operated a PostgreSQL database and a container platform in production, and whether they can take the time away from current duties.
How long does a record-heavy migration take, and what sets that duration?
Duration depends on the number of bases and tables, the volume of attachments, how many logic fields and automations must be rebuilt, and how much validation the business requires before cutover. A base with a few tables and no automations is usually a much shorter exercise than a set of interlinked bases feeding reports. Verification is the step teams most often underestimate: comparing row counts, linked records and attachment integrity per table takes time. Ask any provider for a written schedule tied to a defined scope, and confirm how it accounts for parallel running and cutover weekends.
What does the migration need from our staff?
The work needs named people who know the business logic and can make decisions quickly. Typical requirements include a base owner who can explain each table, field and view, an administrator who can provide hosting access and a domain, and an identity or user owner who can supply accounts and single sign-on settings. Someone must also sign off on which formulas, automations and interfaces are retired versus rebuilt, and who approves the cutover date. Reserve time for user acceptance testing, because staff are the only people who can confirm that filters, sorts and permissions behave as they did in Airtable.
Do single sign-on and audit logs require a paid license in self-hosted Baserow or Grist?
Yes, in both products single sign-on and audit logging sit behind paid tiers, so confirm the license before you plan the design. In self-hosted Baserow, single sign-on through SAML, OAuth 2.0 providers or generic OpenID Connect is available on the Advanced and Enterprise plans with an activated license, and an instance can use only one license type. In Grist, the open-source grist-core repository does not include OIDC or SAML single sign-on or audit log streaming, which belong to the full edition. Grist's full edition is free for individuals and small organizations with less than US $1 million in total annual funding, according to the Grist self-hosting page, and forwarded-header authentication is available in all editions. Confirm your eligibility and the license scope with the vendor.
What should we ask for in a written quote for a self-hosted migration?
Ask for a written scope that lists every base, table and view in scope, the platform and version to be deployed, the hosting environment and who operates it. The quote should separate one-time work (discovery, deployment, migration, rebuild, testing, cutover, documentation) from recurring work (upgrades, backups, monitoring, support). It should state what is excluded, such as formula or automation rebuilds you handle yourselves, and name the acceptance criteria for each deliverable. Ask how the provider verifies record and attachment counts, what happens if the base changes during the project, and which license fees, if any, you pay directly to the software vendor. DeployOpen works from a written scope agreed before work starts, and it does not publish a price list.
How do we confirm record and attachment counts survived the move?
Confirm counts by comparing each table in Airtable with its counterpart in the new platform, then checking attachments and linked records separately. Start with the exact record count per table and view, because a view filter can hide rows in an export. Check that attachment fields contain the expected number of files and that a sample of files opens correctly. Test linked-record relationships by following several links in both systems. Document the results in a reconciliation report signed by the base owner, and keep Airtable read-only until that sign-off is complete so you retain a fallback source.
How DeployOpen sizes, deploys and tests a self-hosted base
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure. For bases that have outgrown Airtable's per-base record and attachment caps, we start by measuring the real table sizes, attachment volumes and access patterns before recommending a platform and a deployment.
How we scope
- Inventory every base, table, view, record count and attachment volume that is hitting the Airtable caps.
- Agree the target platform, hosting location and PostgreSQL arrangement in writing before any work starts.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing; ongoing support is available as a retainer.
How we build
- Size the database, attachment storage and Redis or cache needs for the expected record count and growth.
- Deploy with external PostgreSQL and separate services where the chosen platform documents them for production.
- Test imports on a copy of each base, comparing record counts, attachments, relationships and views before cutover.
How we hand over
- Document the sizing decisions, configuration, backup and restore steps, and upgrade procedure for your team.
- Run a restore test from backup so recovery is proven before go-live, not assumed.
- Confirm which features must be rebuilt, such as formula, lookup and rollup fields, so business owners know what changes.
How we support
- Monitor capacity against the sizing assumptions and flag when tables or attachments approach the limits you set.
- Apply platform upgrades and security patches on a schedule agreed in the retainer scope.
- Re-run performance and security tests as record counts grow, including API load if integrations depend on the base.
