Airtable vs Teable: when each option fits
Start with the trigger, whether that is a renewal notice, a seat-cost review, a data residency rule or a team that needs SQL access to the same tables it edits in a spreadsheet view. Airtable fits teams that want a managed service and can accept its per-base record caps and per-user pricing, which Airtable's plans overview sets at 1,000 records per base on Free, 50,000 on Team and 125,000 on self-serve Business. Teable fits teams that want PostgreSQL underneath and self-hosting, with the database, attachments and access rules on servers the organization runs.
The decision turns on four questions. First, who operates the servers, including backups, upgrades and patching, and whether that work sits with an internal platform team or an outside partner. Second, whether SQL access matters, because Teable's documented SQL query feature only pays off if analysts or applications will read the data directly. Third, which features need a paid self-hosted license: Teable's Community Edition is AGPL-3.0, while AI features and advanced enterprise capabilities are activated with a license key, and the admin panel is described on its pricing page as part of self-hosted Business. Confirm each of these against the current Teable pricing page before budgeting.
Fourth, estimate how much base rebuilding the team can absorb. Teable does not ship a built-in importer for Airtable bases, so the move usually means exporting each table as CSV, since Airtable has no whole-base export, then recreating links, formulas, views and automations by hand. Ask Teable's maintainers and your own pilot base which of these pieces survive the import, and treat that answer as the input to the migration plan. If your Airtable bases are simple and mostly grid views, the rebuild is modest. If they depend on automations and interfaces, plan for that work explicitly.
Which option fits which scenario
This table maps common buyer situations to the better fit between Airtable and self-hosted Teable, with the condition that makes each advantage matter. Read each row against your own constraints, then confirm the open items with the vendors before you commit.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Managed service with no servers to run | Airtable | Airtable is a hosted service with no infrastructure for your team to operate. Teable Cloud is a managed option too, but self-hosted Teable requires you or a partner to run PostgreSQL and the application. |
| SQL access to the tables | Teable | Teable describes itself as built on PostgreSQL and lists SQL query among its features. Confirm with Teable which SQL access level applies to your edition and how permissions map to database roles. |
| EU or in-house hosting for base data and metadata | Teable | Self-hosted Teable runs on servers you choose. Airtable's European region is available only on Enterprise Scale, and base and workspace metadata stay in US data centers regardless of region. |
| AI features and App Builder | Airtable or Teable Cloud | Teable's standalone self-hosted deployment excludes AI features and App Builder. Those need Teable Cloud or a paid license key on the self-hosted image, so confirm which edition includes what. |
| Heavy record volumes in one base | Teable, if sized and tested | Airtable caps records per base at 1,000 on Free, 50,000 on Team and 125,000 on self-serve Business. Self-hosted Teable has no fixed per-base cap in the supplied facts, but practical limits depend on your database sizing, which you should test. |
| Limited operations staff | Airtable | Self-hosting adds backups, upgrades, patching and monitoring for the database and the application. Without that capacity, a managed Airtable plan or a fixed-scope support arrangement reduces operational load. |
| Migration without a built-in importer | Neither, planned work | Teable has no importer for Airtable bases in the supplied facts, so each table is exported as CSV and re-imported. Airtable does not export a full base as one file, so budget effort for attachments, links and formulas. |
How Teable's PostgreSQL foundation changes what your team can do with the data
The main difference this section addresses is that Teable presents a spreadsheet interface over PostgreSQL, so the tables your team edits are real database tables that other tools can query. Teable's repository describes the product as built on PostgreSQL, and its feature list includes an SQL query capability. Airtable's bases are not exposed as a database. You get their contents through the interface, CSV downloads per view and table, or the Airtable Web API, which has its own per-base rate limit. For a team that already runs PostgreSQL, this matters: reporting tools, backup jobs and integrations can read the same data with standard database skills and tooling instead of working through an API.
Confirm the details of Teable's SQL query feature in your own environment before you design around it. Check which statements it allows, whether it is read-only, how it handles permissions for different users, and whether reports can run without loading the spreadsheet interface. Also confirm how backups are scheduled and restored, because the PostgreSQL layer gives you a standard backup path, but Teable's own tables, views and metadata must come back consistently with the data. Ask your Teable administrator or review the Teable GitHub repository for the current documented behavior of the self-hosted image.
A PostgreSQL foundation adds work for a team that only needs views, forms and light automation. Someone must own the database: sizing, patching, monitoring, backup testing and access control for the database role behind the interface. The alternative of a standalone spreadsheet-style tool with its own storage may be simpler to run. If your data team does not already operate PostgreSQL, budget for that skill set first, and treat the database as a production system from day one, not as a convenience layer.
Capabilities side by side: Airtable and Teable
This table compares the capabilities that matter most when moving bases from Airtable to Teable, with Airtable's documented plan caps and Teable's listed features. Where a row is marked to confirm, check the vendor's current page before you plan a cutover, because feature availability differs by plan and edition.
| Capability | Airtable | Teable |
|---|---|---|
| Views and filtering | Confirm which view types and filter options your plan includes on Airtable's views documentation. | Grid, Form, Kanban, Gallery and Calendar views, plus filtering and grouping, are listed. |
| Formulas | Formula fields, lookups and rollups are in use in many bases; confirm function coverage against your own bases. | Formulas are listed; test each formula field you depend on before migrating. |
| Comments, history and collaboration | Confirm comment, record history and simultaneous editing behavior for your plan with Airtable. | Comments, record history and real-time collaboration are listed. |
| Import and export | No whole-base export; each table downloads as its own CSV from a view. | Import and export are listed; editors can import CSV into existing tables since an October 14, 2026 release. |
| SQL query | Confirm with Airtable whether SQL access to base data is offered on your plan. | SQL query is listed, and data sits in PostgreSQL underneath the spreadsheet interface. |
| Automations | Confirm trigger, action and run limits per plan on Airtable's pricing page. | Automation is included in the standalone self-hosted deployment without AI features or App Builder. |
| Admin panel and SSO | Confirm admin controls and single sign-on availability for your plan with Airtable. | Admin panel is listed for self-hosted Business; SSO is listed on Business for Teable Cloud, so confirm self-hosted SSO terms. |
| API and record caps | Web API capped at 1,000 calls per workspace per month on Free and 100,000 on Team; records capped at 1,000, 50,000 and 125,000 per base on Free, Team and Business. | Teable Cloud row caps are 1,000 (Free), 250,000 (Pro) and 1,000,000 (Business) per space; self-hosted limits depend on your database sizing. |
| Licensing and hosting | Proprietary hosted service; Europe or Australia data residency only on Enterprise Scale, with metadata kept in US data centers. | Community Edition is free to self-host under AGPL-3.0; paid features activate with a license key on the same image. |
Teable's editions and what each unlocks
Teable's Community Edition is the code in the teableio/teable repository and is free to self-host under the AGPL-3.0 license. It is the baseline for organizations that want to run Teable on their own servers without paying a subscription for the core product. Teable describes the stack as built on PostgreSQL, so the data sits in a real database the organization can back up and query.
- Core features: Grid, Form, Kanban, Gallery and Calendar views, formulas, filtering, grouping, comments, record history, real-time collaboration, import and export, and SQL query are listed for the project.
- License scope: The main repository is AGPL-3.0, while packages under its packages directory are MIT licensed. Treat these as two separate license sets when you review the code.
- Operating cost: The license fee is zero, but you pay for servers, PostgreSQL administration, upgrades, backups and internal or external support.
- Upgrade path: Teable publishes frequent releases, so plan a repeatable upgrade and test routine rather than a one-time install.
Before you deploy, confirm with Teable which features in the release you plan to run are in the Community Edition and which depend on a paid license.
Teable's official image includes paid plans that unlock AI features and advanced enterprise capabilities. These are activated with a license key, so the organization does not need to swap to a different image or rebuild the deployment. This matters for change control, because the same tested artifact can move from a trial to a licensed state.
- Activation: The license key is entered into the existing deployment rather than installed as a separate build.
- Scope of unlock: AI features and advanced enterprise capabilities are the categories named by Teable. Ask for the exact feature list tied to each plan.
- Admin panel: Teable's pricing page lists the admin panel as available in self-hosted Business.
- Recurring cost: License fees recur on the vendor's terms, so include them in the annual budget alongside infrastructure and staff time.
- Data location: A license key does not move data. The database and the application still run on your infrastructure.
Ask Teable for the current license terms in writing, including renewal, seat or instance counting and what happens to access if a license lapses.
Teable's standalone self-hosted deployment covers tables, collaboration, API and automation. It does not include AI features or App Builder. This deployment suits teams whose needs are the spreadsheet-database core, with records, views, API access and automations running on infrastructure they control.
- Included areas: Tables, collaboration, API and automation are part of this deployment.
- Excluded areas: AI features and App Builder are not part of the standalone option, so any app-building plan has to account for that gap.
- Comparison point: Compare this option with Teable Cloud's full feature set and with the paid self-hosted image to see which features you would give up.
- Operations: Your team owns the PostgreSQL instance, the application, TLS, backups and access control.
- Migration fit: Where bases rely on interfaces or AI-driven workflows, rebuild those on another platform or decide that they are out of scope.
Confirm with Teable which features are present in the standalone package for the version you intend to deploy, because the feature split can change between releases.
Teable Cloud is the hosted offering and is described by Teable as a full-featured self-hosted deployment with AI features and App Builder. It is the option for teams that want the complete feature set without operating the platform, but it is a hosted service, so the data lives with the vendor rather than in your own data center.
- Plans: Teable's pricing page lists Free at $0 with 1,000 rows per space, Pro at $13 and Business at $20 per seat per month billed yearly, with 250,000 and 1,000,000 rows per space respectively, and SSO on Business.
- Row caps: Row limits apply per space and differ by plan, so size each base against the cap that applies.
- Data residency: Hosted data is outside your servers, so review where it is stored and processed against your policy.
- Cost drivers: Seat count, row volume and the plan that includes SSO drive the monthly cost.
- Exit planning: Export data regularly so you can move to a self-hosted deployment if requirements change.
Check the current pricing page and the vendor's data processing terms before you decide, since both can change.
The GNU Affero General Public License version 3 is a strong copyleft license with a network clause. If you modify Teable and make the modified version available to users over a network, the license generally requires you to offer those users the corresponding source code of your modified version. Running an unmodified copy for internal use is treated differently from running a modified copy that others access through a browser or API.
- Internal use: Running the unmodified Community Edition for your own staff is the simplest case, but confirm how your staff access it, including any external users.
- Modifications: Custom views, connectors or patches to the Community Edition can trigger source-availability duties if offered over a network.
- Separate packages: Components under the packages directory are MIT licensed, which carries lighter obligations, so keep a record of which code you touched.
- Paid plans: Confirm whether the license key terms add restrictions on top of the open-source license.
- Third-party code: Dependencies carry their own licenses, which need an inventory.
This summary is not legal advice. Ask counsel to review your intended modifications, your external access model and the license terms of any paid plan before you go live.
Where Airtable and Teable keep records, metadata and accounts
Airtable and Teable put records in different places and manage accounts differently. The questions below decide where regulated data sits, who controls the identity layer, and what evidence an assessor can review.
Airtable metadata stays in the US
Airtable's data residency options for Europe and Australia apply to base data, but base and workspace metadata, user data and authentication data stay in US data centers regardless of the region chosen. For a European bank or health provider, this means the regional choice does not cover the whole footprint. Ask Airtable in writing which data categories fall outside the selected region before you assess the platform.
Residency tied to the top plan
Regional residency for Europe or Australia is available only on Airtable's Enterprise Scale plan, which is priced by custom quote. Teams on Team or Business cannot select that region at all. If residency is a requirement, the plan decision and the data location decision are the same decision, and it should be made before any base migrates.
Teable self-hosted in your infrastructure
Teable's Community Edition is free to self-host under AGPL-3.0, so records, metadata and accounts can live in the cloud account, data center or air-gapped network you choose. Teable describes itself as built on PostgreSQL, which means the database is one you can back up, monitor and restore with standard tooling. Confirm which components of the standalone deployment hold user and session data before you set retention.
Paid features tied to licence keys
AI features and advanced enterprise capabilities in Teable are activated with a license key on the same official image rather than a separate build. The admin panel is listed as part of self-hosted Business. Before you rely on any paid function for access control or audit, confirm with Teable which features the licence key enables and how keys are issued, renewed and revoked.
Single sign-on and admin controls
Single sign-on is listed on Teable Cloud's Business plan, and the standalone self-hosted deployment covers tables, collaboration, API and automation without the AI features or App Builder. Identity integration for a self-hosted Teable instance should be confirmed against the specific edition and version you deploy. Document who can create workspaces, change sharing settings and read the database layer.
Evidence an assessor will ask for
An assessor will typically ask where each data category is stored, who holds administrative access, how access changes are logged, and how backups are encrypted and restored. DeployOpen can prepare the configuration, access records and evidence for these questions, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.
What Airtable seats cost compared with running Teable yourself
Airtable bills per seat with record and API caps that rise by plan, while a self-hosted Teable deployment moves the bill to servers, database administration and staff time. The cards below separate the subscription side from the one-time and recurring costs you carry when you run Teable yourself.
Airtable seat and plan fees
Airtable's pricing page lists Team at $20 and Business at $45 per user per month billed annually, with Enterprise Scale priced on request. Every editor and many read-only users count toward that seat total, so the bill grows with headcount rather than with data volume. Confirm which users need edit rights and whether Enterprise Scale is required for the data residency you need.
Airtable record and API caps
Airtable's plans overview caps records per base at 1,000 on Free, 50,000 on Team and 125,000 on self-serve Business, and API calls per workspace per month at 1,000 on Free and 100,000 on Team. Growing past a cap usually means moving to a higher plan or splitting bases, which adds cost and rework. Check current caps in the plans overview before you size a migration, because these limits change.
Teable Cloud seat prices
If you stay on the hosted service, Teable Cloud lists Free at $0 with 1,000 rows per space, Pro at $13 and Business at $20 per seat per month billed yearly, with 250,000 and 1,000,000 rows per space respectively. SSO is on Business. This gives a direct per-seat comparison with Airtable, but it still leaves data in a vendor cloud, so treat it as a cost baseline rather than a self-hosted option.
Self-hosted licensing and admin panel
The Community Edition is free to self-host under AGPL-3.0, while AI features and advanced enterprise capabilities are activated with a license key. Teable's pricing page places the admin panel in self-hosted Business. Ask the vendor in writing which features each self-hosted tier includes, what the license key costs, how it is renewed, and whether AGPL obligations affect your internal modifications.
Servers, PostgreSQL and backups
Self-hosting adds recurring infrastructure: application servers, a PostgreSQL database with tested backups and point-in-time recovery, storage for attachments, and monitoring. Costs rise with user count, attachment volume and the number of environments you keep, such as staging. Ask your team to estimate these in your own cloud or data center rates, since they vary widely by region and provider.
Migration labor and internal staff time
Teable does not offer a built-in base importer, so each Airtable table is exported as CSV from a view, then imported and relinked by hand. Formulas, lookups, rollups, automations and interfaces must be rebuilt. This is largely one-time labor, but it recurs when you add bases. Costs grow with the number of bases, linked records and automations. Ask any implementation partner for a fixed scope in writing before work starts, and budget internal time for the admins who will run upgrades, identity integration and support afterward.
What moving bases from Airtable involves, step by step
This sequence takes each Airtable base from an inventory of its tables, views and linked records to a Teable workspace that your team uses day to day, with a clear cutover and retirement of the original base.
Inventory every base, table and view
The base owner lists each base, its tables, field types, linked record relationships, views, formulas, lookups, rollups, automations, interfaces and integrations that call the Airtable API. Airtable has no whole-base export, so this list is what tells you how much work each base represents. The step is done when every base has a signed-off inventory sheet that names its owner and its active users.
Export each table as CSV from a view
Someone with edit access opens each table, selects a view that shows all the fields and records you need, and downloads it as CSV, because Airtable does not export a full base as one file. Linked record fields and attachment fields need checking in the exported files, since CSV carries text and links rather than the relational structure. The step is done when each table has a CSV file saved to a controlled location and the row counts match what Airtable shows.
Plan the attachment transfer
Attachments are not part of the CSV, so the team downloads them separately and keeps a mapping from each record to its files. Attachment links in Airtable are temporary, so downloads should happen while the base is still live and checked by file count and size. Re-linking uses the new file locations in the target. The step is done when a manifest shows every attachment, its source record and where its copy is stored.
Design the target tables in Teable
Teable runs on PostgreSQL, so the team decides the target table structure, field types and link fields before importing. Each Airtable linked record field becomes a relationship that must be recreated, and single select, date and number fields should be typed deliberately. Confirm in the Teable documentation how each field type is represented. The step is done when a written schema lists every table, field, type and relationship, and a test space has been created with it.
Import CSV files and check the data
Import the CSV files into the Teable tables. The supplied facts do not include a built-in Airtable importer for Teable, so this import is a manual CSV process. The October 14, 2026 Teable release let editors import CSV files into existing tables, so confirm how that import behaves with your field types, linked records and attachments before relying on it. The step is done when row counts, sample records and linked relationships match the Airtable source for every table.
Rebuild formulas, rollups, views and automations
Rebuild every formula, lookup and rollup field, each saved view, and each automation by hand in Teable, using the Airtable inventory as the checklist. Teable lists Grid, Form, Kanban, Gallery and Calendar views, formulas, filtering, grouping and an API, but automations and interfaces need to be verified against your own workflows. Each rebuilt item is tested with real sample records. The step is done when a test matrix shows each formula, view and automation producing the same results as in Airtable.
Pilot with a subset of users
Choose a small group of users and one base that represents typical use, then have them work in Teable while Airtable remains the source of record. Collect issues on data entry, permissions, views, attachments and integrations in a shared log. The step is done when the pilot group signs off on the list of differences and every blocking issue has an agreed fix.
Cut over and retire the Airtable bases
Freeze edits in Airtable, run a final export and import for changed records, switch integrations and users to Teable, and keep the Airtable bases read-only for a period agreed by the business owner. Retirement happens only after the final reconciliation and after confirming that archived data and attachments are stored where your retention policy requires. The step is done when every base has a recorded cutover date, an archive location and a documented owner for the Teable workspace.
What running Teable on your own servers asks of your team
Self-hosting Teable moves a set of recurring operating tasks to your team. Deploying the official image is the easy part. The team then owns the PostgreSQL database underneath, including scheduled backups, tested restores, major and minor version upgrades, storage growth and monitoring. Because Teable presents real PostgreSQL behind the spreadsheet interface, a failed restore or an unmonitored disk affects every base at once. Identity also stays with you: sign-in, user provisioning and offboarding need to be configured and reviewed, and the paid license key for AI features and advanced enterprise capabilities has to be installed, renewed and tracked as a separate item.
Airtable's hosted service carries most of this work for you, including database operations, platform patching and capacity. What stays with your team under either model is the data itself and the access rules: who can see which base, which fields are restricted, which API tokens exist and who reviews them. Teable publishes frequent releases, including two in mid-October 2026 that added an MCP server and CSV import into existing tables. Each release should be read against your own configuration, restored into a staging copy of the database, and exercised with your key bases and automations before it reaches production. Confirm the exact upgrade path and any breaking changes in the release notes before you schedule a change window.
Assign one named owner for the platform, with a deputy who can restore the database, and make sure the owner also controls the license key and the upgrade calendar. Capacity planning should start from your current row counts and grow with them, so review storage and query performance on a fixed schedule rather than waiting for complaints. Many organizations keep this in-house and add a retainer for ongoing support and upgrades when release cadence, on-call coverage or staff turnover outpace internal capacity. Ask any provider to state in writing what the retainer covers, how upgrades are tested, and who is responsible when a restore fails.
Questions buyers ask before moving from Airtable to Teable
What does a move from Airtable to self-hosted Teable cost?
The cost is mostly people time and infrastructure, not a license fee for the Community Edition, which is free to self-host under the AGPL-3.0 license. The main one-time costs are migration work (exporting each table, rebuilding formulas, automations and views, and testing), plus setting up a PostgreSQL database and hosting. Recurring costs are the servers, backups, upgrades and the staff time to run them. If you want paid features such as the admin panel, which the pricing page places in self-hosted Business, add the license cost for that tier. Ask any provider for a quote that separates one-time migration work from recurring operations and lists which Teable features each tier includes.
How long does a migration from Airtable to Teable take?
No duration can be stated reliably here, because it depends on how many bases you have, how many records and attachments they hold, how many formulas, automations and interfaces must be rebuilt, and how many people must test them. Teable has no built-in base importer comparable to the one Baserow documents, so table-by-table work is usually the largest variable. Ask for a written scope that lists each base, the rebuild items, the test cases and the cutover steps, and compare timelines only against that scope.
Can our own team migrate from Airtable to Teable without outside help?
A team with PostgreSQL and container experience can run a small pilot alone, especially for a few simple bases. The difficulty rises with linked records, attachments, lookups, rollups and automations, because these need deliberate table design and retesting. Each Airtable CSV export is per table and per view, so the team must handle relationships and attachment links itself. Decide early whether internal staff have time for the rebuild and ongoing operations, and treat that as a staffing question as much as a technical one.
What do we need to provide for a Teable migration?
You need a named data owner for each base who can confirm which records, fields and views matter, and an administrator who can provision the servers, the PostgreSQL database, storage and single sign-on where required. Testers from each team should check record counts, formulas and views against the original base before cutover. Plan for a PostgreSQL operator who handles backups, restores, upgrades and access control, because Teable sits on a real database. Name these roles in the written scope before work starts.
Can Teable replace Airtable Automations and Interfaces?
Teable lists formulas, filtering, grouping, comments, record history, import and export, SQL query and automation among its features, so simple automations can often be rebuilt there. Airtable Interfaces are not a direct match, and no importer carries automations over, so each one must be recreated and tested by hand. Check each automation's triggers and actions against Teable's current documentation, and confirm whether the self-hosted tier you choose includes the automation and app-building features you need, since Teable's App Builder is listed for Teable Cloud rather than the standalone self-hosted deployment.
Is direct SQL access to our data worth the extra operating load?
Direct SQL access helps when reports, data pipelines or other applications need the same tables, because Teable is built on PostgreSQL and exposes the data through a spreadsheet interface and SQL query. It also means your team must operate a database, which adds work for backups, patching, role-based access, monitoring and capacity planning. If your use is mainly a small team's spreadsheet work, a simpler self-hosted option may suit you better. Decide based on who will query the data and how often.
How do we check Teable's current license terms and features before committing?
Read the license files in the teableio/teable repository, since the Community Edition is under AGPL-3.0 while packages in its packages directory are MIT licensed, and have counsel review what AGPL-3.0 means for your use, including any modifications you make. Then compare the features of each self-hosted tier against your requirements on the pricing page, and confirm with the vendor which features require a license key. Teable publishes frequent releases, so check the release notes for changes before you sign anything and again before cutover.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements and hands over self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Airtable vs Teable, we start with a written scope that tests whether your bases fit Teable's PostgreSQL-backed model before any migration work begins.
How we scope
- We inventory your bases, views, formulas, automations and attachments to see which parts Teable covers directly.
- We confirm which Teable features you need, including whether paid self-hosted license keys are required for them.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy Teable's Community Edition in your environment on PostgreSQL, with the access controls and backups you specify.
- We script the table-by-table CSV import, re-link attachments and check record counts and linked fields against Airtable.
- We rebuild formulas, views and automations in Teable and test each one against the original base's behavior.
How we hand over
- We document the deployment, configuration, backup procedures and the field-by-field mapping from each Airtable base.
- We record which automations and interface patterns were rebuilt, changed or left out, so your team knows what differs.
- We walk your administrators through daily operation, SQL access to the data and the upgrade path for new releases.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We can re-test the deployment when Teable publishes new releases that change views, imports or the admin panel.
- We prepare systems, controls and evidence for compliance assessments, while independent auditors issue any attestation.
