Comparison
|
Jun 4, 2026
Airtable vs. Directus
An honest (as we can get) comparison between Airtable and Directus. Data ownership, record limits, API access, licensing, AI, automation, pricing, and where each one breaks down.
Matt Minor
Senior Director, Growth
Note from Directus
Yes, this is a Directus vs Airtable page written by Directus. Yes, we know that's absurd. Since we have to publish ours or you won't find a comparison from our perspective, we'd rather play this game differently. What follows is the most honest comparison we could write.
One stores your data. One wraps yours.
Airtable is a hosted product that stores your data in…Airtable. You get a spreadsheet-style grid, an interface builder, automations, and AI on top of a proprietary store you cannot host, query with SQL, or point another service at.
Directus is a backend platform that stores your data in a SQL database you own. It reads any existing Postgres, MySQL, MariaDB, MSSQL, SQLite, Oracle, or CockroachDB schema and exposes it through REST, GraphQL, and realtime APIs, with a workspace UI, visual automation, dashboards, and AI on top.
The feature-by-feature view.
Directus | Airtable | |
|---|---|---|
Where your data lives | A SQL database you own and control | Airtable’s proprietary store |
Self-host | Yes, including a free to host Core tier. | No |
License | Source-available (custom Monospace license) | Proprietary, closed source |
Databases supported | Postgres, MySQL, MariaDB, MSSQL, SQLite, Oracle, CockroachDB | None. Airtable is the database |
API output | REST, GraphQL, WebSockets, GraphQL Subscriptions | REST only |
API rate limit | Your infrastructure | 5 requests/sec per base, 50/sec per token |
Realtime subscriptions | Native WebSockets and GraphQL Subscriptions | No. Webhooks for change notification |
Admin UI | The Studio (Vue 3) | Grid views, Interface Designer |
Visual automation builder | Flows | Automations |
Native dashboards | Insights | Interface Designer dashboards |
Native AI assistant | Yes, AI Assistant in the Studio | Yes (Omni, Field Agents), metered by credits |
Native MCP server | Yes | Yes, launched February 2026 |
Field-level permissions | Yes | Team plan and above |
Row-level access rules | Yes | No |
The main architectural difference.
That design is what makes Airtable fast to start with. No database to provision, no hosting decision, no migration story. You open a browser and you have a working table in a minute. That is how Airtable spread through so many companies without an IT project attached.
It also means your data is only as reachable as Airtable's API allows. Every downstream system, every report, every internal tool, and every AI agent is a client of that API and inherits its rate limits, its record caps, and its availability.
Where the difference actually shows up
Analytics wants to query the data. With Directus, you can connect a BI tool to Postgres. With Airtable you build a sync, or pay for one, and work from a copy.
A page load needs 5,000 records. With Directus that's a database query. With Airtable that's paginated REST calls against a 5 requests per second per base ceiling, which is why most production Airtable setups end up with a caching proxy in front.
Data has to stay in a region or your own VPC. With Directus you self-host it. With Airtable that requires the Enterprise Scale plan.
A second service needs write access. With Directus both services talk to the same database. With Airtable both queue behind the same rate limit.
These are different bets about who should own the storage layer. Airtable's bet works as long as you stay inside its boundaries. Directus' bet holds when your data needs to outlive any one tool and stay reachable by anything in your stack.
Source-available vs. closed SaaS.
Airtable is proprietary, closed-source software delivered only as a hosted service. There is no self-hosted option, no source access, and no way to run it in your own environment. Data export is per-table CSV or through the API.
Schema, interfaces, automations, and permissions do not export in a portable form: if you leave, you re-create all of them somewhere else. For teams with data residency requirements, air-gapped environments, or procurement rules about where regulated data can live, this is a hard constraint rather than a preference.
Directus is source-available under a custom Monospace license (the live terms are at directus.com/license). We are specific about this because it cuts both ways. Directus is not open source by the OSI definition and we don't claim it is.
What Directus does give you that Airtable does not:
Readable source, self-hosting on every tier, and a database you already own. Your data portability does not depend on our license or our export tooling, because your data is in your Postgres instance.
If your requirement is "we must be able to run this ourselves and keep our data in our own database," Airtable cannot meet it at any price and Directus can meet it for free.
Permissions.
Airtable's permission model is workspace, base, and interface roles (owner, creator, editor, commenter, viewer), plus field and table editing permissions on Team and above. Field permissions grey out a field for users without edit access, everywhere it appears. Interface-only roles let you expose a screen without the base behind it. It's quick to configure, and it stops at roles.
The limits show up when the rules get conditional. Airtable's permissions are role-based per base, table, and field. They are not row-level: you cannot natively say "this user sees only records where owner equals their user ID" as an access rule, which is why Airtable teams commonly reach for filtered interfaces or a third-party front-end when they need per-record access control.
Directus permissions are roles and policies with per-collection, per-field, and per-item rules, including filter-based item permissions that evaluate against the record and the current user. Field-level permissions are on every tier, including free self-hosted. The same policies govern the Studio, the REST and GraphQL APIs, and the MCP server, so an AI agent operates under exactly the access rules a human with that role would have.
Data modeling.
Airtable models data as bases containing tables, with fields typed for the interface: single line text, long text, attachment, single select, linked record, rollup, lookup, formula, and so on. Linked records connect tables. Rollups and lookups pull values across links. It is a spreadsheet-database hybrid, and non-technical users pick it up quickly.
The modeling limits are the ones you would expect from that lineage. There are no real foreign key constraints, so referential integrity is Airtable's behavior rather than the database's guarantee. Formula, rollup, and lookup fields compute inside Airtable, so their results are only available where Airtable evaluates them. There is no schema-as-code, so promoting a change from a staging base to production is manual work or a scripted rebuild. And because the model is Airtable's, the shape your other systems consume is Airtable's shape.
Directus models data as actual database tables with actual columns and actual foreign keys. A collection with twenty fields is a table with twenty columns. Many-to-many is a junction table. Many-to-Any (M2A) connects one collection to items across several others. Constraints are enforced by the database, not the UI. Schema changes propagate between environments with Schema Snapshots. Computed values are database views, generated columns, or Flows, all of which any consumer of the database can see.
For a small operational tracker the difference does not matter. For a data model that other services depend on, a normalized relational schema with real constraints is the one that stays correct as the number of writers grows.
Automation and workflows.
Both ship a visual automation builder and both are usable by non-developers, which makes this one of the closer sections on the page.
Airtable Automations run on triggers (record created, record updated, scheduled, form submitted, webhook received) with actions for creating and updating records, sending email and Slack messages, running scripts, and calling other apps. Run volume is metered: the Team tier is documented at 25,000 automation runs per month, and heavier use pushes you to Business. Scripts run in Airtable's sandboxed JavaScript environment.
Directus Flows run on data events, webhooks, and schedules, with conditions, transforms, request operations, and custom JavaScript at any step. Runs are not metered, but Flow count is tiered: 5 on Core, 20 on Team, unlimited on Enterprise. Self-hosted Flows run on your infrastructure.
The honest read: Airtable's trigger and action library is broader out of the box, because maintained integrations come with being a hosted product. Directus Flows go deeper on data manipulation, run on your infrastructure, and do not meter execution, which is what matters when an automation fires on every record change in a high-volume table. Metered automation runs are a cost that scales with how much work your business actually does.
Realtime and APIs.
Airtable exposes a REST API only. No GraphQL, no client subscription API. For change notification there is a webhooks API that pushes base changes to an endpoint you host. That is enough to trigger work when data changes. It is not enough to push live updates to connected clients, so live-updating UIs on Airtable data require your own realtime layer in between.
Directus generates REST and GraphQL from the schema and ships native WebSockets and GraphQL Subscriptions in core. Clients subscribe to a collection and receive changes, governed by the same permission policies as any other request, no additional infrastructure.
If your product has a live dashboard, a collaborative view, or anything where two people need to see the same data update, Directus covers it natively and Airtable does not.
AI.
Both platforms ship AI, and this is a section where the older comparison talking points have gone stale, so we will be precise.
Airtable has Omni, a conversational builder that creates tables, interfaces, and automations from natural language, and Field Agents, which run research, analysis, and content generation tasks across records at scale. You can select the underlying model (OpenAI, Anthropic, Meta), and Airtable states that models do not retain or train on your data. Airtable also shipped an official MCP server in February 2026 at mcp.airtable.com, giving MCP-compatible clients read and write access to your bases under your account's existing permissions.
The constraints are metering and scope. AI usage runs on credits: 500 per editor per month on Free, 15,000 per billable collaborator on Team, 20,000 per paid user on Business, 25,000 on Enterprise Scale, with data analysis responses documented at 10 credits each. Building with Omni does not consume credits, but agent and analysis work does, and additional credit packs are a real line item for teams that lean on it. On the MCP side, the official server is scoped to a chat session you initiate: it has no trigger model, so a new record landing in a table cannot start anything through MCP, and record creation is capped at 10 records per request.
Directus ships an AI Assistant in the Studio that is conversational and takes action: create and edit content, translate fields, summarize records, route items for review, all under the same access policies as a human user in that role. Directus also runs a native MCP server, so external clients (Claude Desktop, Cursor, ChatGPT, your own agents) work against the same data through the same permission model. Usage is not credit-metered. Enterprise plans support bringing your own LLM, which matters if your model choice is a compliance decision rather than a preference.
The real difference is not "who has AI." It is what the agent is operating on. An Airtable agent works on records inside Airtable, through Airtable's API, at Airtable's limits. A Directus agent works on your database, under your policies, alongside every other service that reads from it.
If your AI plan is "agents help us run the business on top of the system of record," the question of what the system of record actually is comes first, and that is the architectural question from the top of this page.
Extensibility and developer experience.
Airtable extends through Scripting (JavaScript in a sandbox), custom apps built with the Blocks SDK that render inside a base, the REST API, and the webhooks API. There is a marketplace of apps and a large ecosystem of third-party tools built specifically to fill Airtable's gaps: Softr, Noloco, Fillout, Zapier and Make for integration, Stacker and similar for portals. That ecosystem is large, and it exists because those gaps do. Every tool on that list is a line item and an integration you maintain.
Airtable also sells Portals as an add-on for external guest access, commonly quoted around $120 to $150 per month for 15 guests. Budget for it if client-facing access is part of your plan.
Directus is Node.js and TypeScript throughout. The extension model covers endpoints, hooks, modules, layouts, interfaces, displays, panels, operations, and bundles, all written in TypeScript. The SDK is TypeScript. For a JS or TS team the whole stack is one language and extensions are ordinary code in your repo, versioned and reviewed like everything else.
What it actually costs.
Airtable
Per seat, billed for every user with edit permission on at least one base in the workspace.
Free: $0, 1,000 records per base, 1,000 API calls per workspace per month
Team: $20 per user per month billed annually, 50,000 records per base
Business: $45 per user per month billed annually, 125,000 records per base
Enterprise Scale: custom pricing, 500,000 records per base
Directus
Core: $0, 3 seats, 25 collections, 5 Flows, AI Assistant, advanced RBAC
Team: $499 per month billed annually ($599 monthly), 10 SSO seats, 50 collections, 20 Flows, granular RBAC, additional seats $50 each
Enterprise: custom, custom SSO seats and collections, unlimited Flows, SAML/OIDC, bring-your-own LLM, offline mode
Self-hosting is free on every tier. Directus Cloud is a $99 per month add-on on Core and Team.
Running the numbers
Small team, small data. A 3 person team with a few thousand records: Airtable Free may cover it, and self-hosted Directus Core covers it too at $0 plus your hosting. Roughly a tie, and Airtable is faster to stand up.
Mid-size team. 15 people who need edit access, on Airtable Business at $45 per seat annual: $8,100 per year, capped at 125,000 records per base and 100,000 per table. On Directus Team at $499 per month: $5,988 per year for 10 SSO seats, plus $50 per month per additional seat, so 15 seats lands around $8,988, with no record or API caps and self-hosting included. Comparable money, different constraints. Airtable is cheaper here if your data stays under the caps and you value not running infrastructure. Directus is the better value if the caps are in play.
Larger team. The per-seat curve is where Airtable's model bites. 40 seats on Business at list is roughly $21,600 per year, and it keeps climbing linearly with headcount while the 100,000 records per table ceiling stays exactly where it is. Directus Enterprise is custom-quoted, and often comes in much lower than the bigger players in the content / data space.
Two Airtable line items teams miss:
AI credit packs (commonly around $40 per month for 20,000 credits
Portals add-on for external guests, anywhere from $120 - $150 per month.
And as of October 2025 Airtable no longer prorates refunds when you remove seats mid-cycle, so you pay through your renewal date. If your headcount fluctuates, model the peak.
Neither is perfect.
Three areas where Directus is weaker | Three areas where Airtable is weaker |
|---|---|
No app builder. Interface Designer has no Directus equivalent, and there's nothing like Omni generating a working app from a prompt. Customer-facing screens are your front-end to build. | Your data lives in Airtable's proprietary store. No SQL access, no connection string, no self-hosting, no way to point another service at the same tables |
Non-technical users usually get further alone in Airtable. The Google Sheets style UI is more intuitive from the start. Directus marketplace offers spreadsheet-style editing extensions, but it is not equipped "out of the box." | API rate limits of 5 requests per second per base make Airtable a poor fit under a production application without a caching layer in front. |
Fewer maintained turnkey integrations. | REST only. No GraphQL, no client subscription API, so live-updating clients need a realtime layer you build. |
Migration notes.
Airtable to Directus.
This migration is more approachable than most, because Airtable's model maps reasonably onto a relational schema. Export each table to CSV or pull it through the REST API, design the destination tables with real columns and real foreign keys, and import. The parts that need decisions:
Linked records become foreign keys or junction tables. One-to-many is a foreign key. Many-to-many is a junction table. This is usually an improvement in queryability.
Formula, rollup, and lookup fields do not transfer as data. Re-create them as database views, generated columns, or Flows, depending on whether you want them computed on read or on write.
Attachments are URLs in Airtable's store. Download them and re-upload to your Directus storage adapter (S3, GCS, local) before those URLs expire.
Interfaces do not transfer. If an interface was serving end users, that becomes a front-end or a Studio workflow.
Automations do not transfer. Rebuild them as Flows. The trigger and action concepts translate closely.
Permissions need re-modeling, and this is usually where teams gain rather than lose, because Directus policies express rules Airtable's roles could not.
For a base with a handful of tables and no heavy formula logic, this is a day or two. For a workspace with many linked bases, deep rollup chains, and interfaces in production, plan for longer and migrate table groups in stages. Rate limits apply to the export side, so budget time for pulling large tables at 5 requests per second per base.
Directus to Airtable.
Possible for small datasets, and constrained by the caps. Any table over 100,000 rows does not fit, full stop. Relational structure flattens into linked records without database-enforced constraints. Extensions, custom endpoints, and realtime consumers have no Airtable equivalent and would need rethinking.
Common questions.
Is Airtable a database?
Not in the sense that matters for engineering decisions. Airtable stores structured, relational-looking data and calls its containers bases, but there is no SQL interface, no connection string, and no way for another service to query the store directly. Everything goes through Airtable's REST API. If your definition of database includes "another system can connect to it," Airtable is not one, and that is the single most important thing to understand before building on it.
Can I self-host Airtable?
No. Airtable is a closed-source hosted service with no self-hosted option at any tier. If self-hosting is a requirement, Airtable cannot meet it. Directus is free to self-host on every tier.
We haev 200k records in one Airtable. What are our options?
You do not have 200,000 records in one Airtable table, because the per-table cap is 100,000 on every plan. The usual workarounds are splitting across tables, archiving to an external store, or syncing a read-only subset from HyperDB (Enterprise only, beta, 250,000 record subset cap, not writable). If a single large writable table is central to your model, that is the point where teams move the data to a real database, and Directus is designed to be the workspace on top of it.
Is Directus a replacement for Airtable?
For data management, permissions, automation, dashboards, and API access, yes, and with a database you own and no record caps.
Can I use Directus and Airtable together?
Some teams do, with Airtable as a front-of-house tool for a specific team's workflow and Directus over the SQL database that runs the product, syncing between them through Flows and Airtable's API. It works, and it is worth being clear-eyed that you are then maintaining two systems of record and a sync, which is usually a transitional state rather than a destination.
