Elements vs Airtable
Airtable is a hosted database you use like a spreadsheet. A team keeps its records in bases of linked tables, builds Interfaces on top of them so each person sees the screens their job needs, and wires up automations that act when records change. Airtable's AI can build apps and agents inside a workspace as well (AI billing (opens in a new tab)). Many teams run a real business process this way: a CRM, inventory, a project tracker, an order desk. Airtable sells it per collaborator on its Team and Business plans, and each plan sets the records a base can hold, the attachments it can store, the automation runs a workspace gets each month and the API calls it can make (plans overview (opens in a new tab)).
Airtable is a no-code app platform: a hosted place where a team builds the software its process runs on without writing code.
Elements plays in that category directly. It is a project server that runs while you work, and it ships with a default framework that just works, so you and your agent build the app your process runs on. You tell Claude Code, or the agent you already use, how your team works, and it builds the app: a Postgres database for your records, sign-in for your team, pages that update live in every open browser, background jobs and email for the work automations do. Elements builds in milliseconds and answers agents and humans in microseconds, reporting each error with its file and line, so the agent fixes it before you open the page. One command deploys the app to a server you control. You pay Elements per machine, and nothing is metered (pricing (opens in a new tab)).
The difference is what grows your bill. On Airtable, every teammate who edits is a seat, and every record, run and API call counts against a plan limit. On Elements, nothing is metered, and Elements licenses machines, not users (licenses (opens in a new tab)).
| Elements | Airtable | |
|---|---|---|
| What you get | A real app: pages, server code and a Postgres schema, in your own project | Bases of tables, with Interfaces built on top |
| Who builds it | You and your agent: Claude Code, Codex, Cursor or another | You, in Airtable's editor, with Airtable's AI |
| What you pay for | Machines: the one you build on and each server you deploy to | Each collaborator who can edit, and on Team each commenter too |
| Records | No Elements limit; your tables live in Postgres | 1,000, 50,000 or 125,000 per base, by plan |
| Attachments | Stored in Postgres or any object store | 1 GB, 20 GB or 100 GB per base, by plan |
| Background work | Jobs and cron, built in and unmetered | 100, 25,000 or 100,000 automation runs per workspace a month |
| Reaching the data from code | sql() inside the app, against standard Postgres |
Web API at 5 requests per second per base, with monthly caps on Free and Team |
| Outside users | Sign-in built in, with no charge per user | Portals, an add-on sold in packs of seats |
| AI | The agent you already pay for; Elements meters nothing | Monthly credits per seat, with packs to buy more |
| Where it runs | Ubuntu servers you control, over SSH | Airtable's service |
Every Teammate Is Included
Airtable bills by the person. On Team, Airtable's billing guide (opens in a new tab) counts workspace owners, creators, editors and commenters, base editors, and interface editors and commenters as billable, and adds that "a collaborator you add as a Commenter to keep costs down still adds to a Team plan bill." Team is $20 per collaborator a month billed annually, or $24 billed monthly; Business is $45, or $54 (plans overview (opens in a new tab), pricing (opens in a new tab)). A process that touches the warehouse, the front desk and sales puts every one of those people on the invoice.
An Elements app has accounts, not seats. Your agent builds sign-in with a users table in your own database, and roles decide who edits what (session (opens in a new tab), authentication recipe (opens in a new tab), admin roles recipe (opens in a new tab)). Add the entire floor staff, or give a contractor an account for a week, and the Elements price stays the same.
Your Tables Grow With Your Business
A base has a ceiling. Airtable's plans overview (opens in a new tab) allows 1,000 records per base on Free, 50,000 on Team and 125,000 on Business, and "your plan's record limit is cumulative over different tables." Attachments stop at 1 GB, 20 GB or 100 GB per base. At either limit, Airtable's pricing page (opens in a new tab) says you "will not be able to add more records or attachments until you upgrade to a new plan."
In Elements, your records are rows in Postgres, and Elements sets no record limit. Elements installs its own Postgres on your computer and on each server you deploy to, and creates the app's databases for you (database (opens in a new tab)), so orders, customers and stock levels live in one database where a query can join them. Uploaded files arrive as File objects and are stored in Postgres or any object store (file upload recipe (opens in a new tab)). When the app scales out to several servers, they share one Postgres that you run or that a managed provider runs, set with DB_HOST, and every feature works across all of them (deploy setup (opens in a new tab)).
Background Work Runs on Your Schedule
Airtable automations draw from a monthly allowance: 100 runs per workspace on Free, 25,000 on Team and 100,000 on Business, and Airtable "counts a run each time an automation's trigger is invoked." When a workspace reaches its limit, the plans overview (opens in a new tab) offers two choices: "wait for the allowance to reset on the first of the next month" or "upgrade the workspace to a plan with a higher limit." Until then, the workspace's automations do not run.
Elements runs background work as jobs and cron, built in and never counted (jobs (opens in a new tab)). The queue lives in the same Postgres as your records, so a job scheduled inside a transaction commits with the order that caused it, or not at all. A failed job retries with backoff. A daily task is one line in the app:
app.cron("every day at 8am", "low stock", () => new LowStockAlertJob().schedule());
The job itself sends email through any SMTP provider, from a template written in the same HTML as your pages (email (opens in a new tab)).
Your Code Reads the Database Directly
Code that works with Airtable goes through its Web API, and the API has limits. Airtable's rate limits page (opens in a new tab) says "The API is limited to 5 requests per second per base," and a client that goes over gets a 429 and "will need to wait 30 seconds before subsequent requests" succeed. On top of that, Free workspaces get 1,000 calls a month and Team workspaces 100,000 (plans overview (opens in a new tab)).
In an Elements app, the integration is part of the app. Server code reads and writes with sql(), and pages call typed @rpc functions directly (database (opens in a new tab), rpc (opens in a new tab)). A job can pull from a supplier's feed or push to your accounting system on a schedule, with no per-second budget between your code and your data. Because it is standard Postgres, any tool that speaks Postgres can connect to it. Agents build from standards they already know, HTML, CSS, SQL and TypeScript, and every npm package installs as is, so a connection to another service is ordinary code in your app.
Every Screen Updates Live
Interfaces give each role its own screens. An Elements app does the same with pages written in Elements HTML: standard HTML with e:if, e:for and {} around values that change, rendered on the server and reactive in the browser (html (opens in a new tab)). A search-and-filter table with inline actions is a worked recipe your agent starts from (admin table recipe (opens in a new tab)).
A LiveTable keeps those screens current. The page renders with its rows in the first response, a change appears at once in the browser that made it, and every other open browser patches the same row in place, across every app server (livetable (opens in a new tab)). When the warehouse marks an order shipped, the sales screen shows it without anyone asking. Rows can be split per team, with membership checked in the route and in every write (team partitioned table recipe (opens in a new tab)).
Customers and Partners Sign In to the Same App
Airtable sells access for outside users separately. Portals (opens in a new tab) are "available as an add-on on our Team, Business, and Enterprise Scale plans," starting at "$120 per month for 15 portal seats" on Team and "$150 per month for 15 portal seats" on Business, in packs of 15 up to 200.
In Elements, a customer, a supplier or a franchisee signs in to the same app your team uses, through the same session API, and sees what their role allows (session (opens in a new tab)). A customer portal is more pages in your app, and the hundredth customer costs Elements nothing more than the first.
AI Without a Credit Balance
Airtable's AI features draw from credits allotted per seat: 15,000 a month per billable collaborator on Team and 20,000 per paid user on Business, pooled across the workspace or organization, with included credits expiring "at the end of each month" (AI billing (opens in a new tab)). A question costs 10 credits, and a document analysis 200. More credits come in packs, such as 10,000 credits for $20 a month.
With Elements, the AI is your agent: Claude Code, Codex or whichever you already pay for. It builds the app on your computer, and Elements never meters what it does. The checking is not AI work either. The compiler and your tests check each change, and elements build -json returns every error with its file and line (build (opens in a new tab)), so your agent spends its effort on the fix.
Deploys Are Gated by Your Tests
When the app is ready, elements deploy ships it to any Ubuntu server you reach over SSH (deploy (opens in a new tab)). On the first deploy, Elements sets up the server with Postgres, its built-in load balancer and TLS certificates. Before a release goes live, your tests run on every machine and pending migrations run once. If anything fails, the previous release keeps serving (what deploy does (opens in a new tab)). Each deploy after the first carries only the changed files, so a fix is live in under a second.
One Price, Known Up Front
An Elements subscription (pricing (opens in a new tab)) starts with two licenses, one for the machine you build on and one for the server you deploy to (licenses (opens in a new tab)). Nothing is metered: a new user, a new table or a busy month leaves the Elements price where it was. Your server provider charges its own monthly price. The runtime packages such as @elements/app are MIT licensed, so the app you ship is TypeScript, HTML, CSS and SQL on standard Node.js and Postgres, and the code is yours.
Questions
Is Elements an Airtable alternative?
Yes. Instead of running your process in hosted bases, you and your agent build the real app on Elements: a Postgres database, sign-in, live pages, background jobs and email, deployed to a server you control. You pay per machine, not per editor.
Do I need to know how to code to replace Airtable with Elements?
No. You tell Claude Code or another AI agent how your team works, and it writes the app. Elements checks every change and tells the agent what to fix. You can read and change every line yourself whenever you like.
How do I move my Airtable bases to Elements?
Give your agent the job, with your bases as the spec. Each table becomes a Postgres table written as a SQL migration, linked records become foreign keys, and your agent copies the records over through Airtable's Web API. Interfaces become pages, and automations become jobs and cron. elements build -json checks every step.
Does Elements charge per user like Airtable?
No. Elements licenses machines: the one you build on and each server you deploy to. Your team, your customers and your partners can all have accounts in the app without changing the Elements price.
Is there a record limit in Elements?
Elements sets none. Your records are rows in the Postgres that Elements installs on your computer and on each server. When the app scales out, your servers share one Postgres that you run or that a managed provider runs.
What replaces Airtable automations?
Background jobs and cron, built into Elements and never counted. The job queue lives in the same Postgres as your records, failed jobs retry with backoff, and email goes out through any SMTP provider.