Airtable vs Self-Hosted NocoDB: The Database Bill at 50k+ Records

There are two ways an operational database gets expensive, and most teams only budget for one of them. The first is the record ceiling, which is the number people talk about. The second is the seat count, which is the number that actually shows up on the invoice.

Both tend to hit around the same time, because the same growth that fills up a base also adds the people who work in it. That is when the searches start for an Airtable alternative, and NocoDB self-hosted is usually the first result worth taking seriously.

This post does the arithmetic honestly in both directions, including the cases where staying on Airtable is clearly the right call. All figures below come from published pricing and should be treated as estimates. Vendors change plans, and you should confirm current numbers before signing anything.

Where Is Airtable's Actual Pricing Cliff?

Airtable pricing has two axes that matter to an ops team: what you pay per person, and how many records you are allowed to keep in a single base. Here is roughly where the published tiers sit.

• Free: around 1,000 records per base, about 100 automation runs per month, roughly 1 GB of attachments. Useful for testing, not for running a business.
• Team: around $20 per editor per month billed annually, or roughly $24 billed monthly. About 50,000 records per base, roughly 20 GB of attachments per base, and around 25,000 automation runs per month.
• Business: around $45 per editor per month billed annually, or roughly $54 billed monthly. About 125,000 records per base, roughly 100 GB of attachments per base, around 100,000 automation runs, plus SAML single sign-on, an admin panel, and two-way sync.
• Enterprise Scale: quoted individually. Published materials put the ceiling at roughly 500,000 records per base with much higher automation allowances.

The detail that catches people out is that these caps are per base, not per workspace. You can have twenty bases on a Team plan and none of them may exceed the cap individually. That is also the escape hatch most teams discover on their own, and we will come back to what it costs you.

One more constraint that matters if you are automating against Airtable rather than clicking around in it: the API is rate limited at a small number of requests per second per base. If you are syncing loads or orders in bulk, that limit shapes your integration design long before the record cap does.

Why the Seat Bill Is Usually the Real Bill

Take a freight brokerage in the GTA doing steady volume. Three dispatchers, two people on billing and claims, an ops manager, the owner, and one part-time person handling carrier packets. That is eight people who need to edit, not just view.

On Business billed annually at roughly $45 per editor, that is about $360 per month, or roughly $4,320 per year. Billed monthly at around $54 it is closer to $432 per month, about $5,184 per year. Hire three more dispatchers next year and you add roughly $1,620 annually at the same rate, before anyone touches a record.

Seat counting rules also differ by plan tier. Read-only sharing is generally free, but anyone with edit rights counts, and on some plans commenter access counts too. Check the specific rule on the plan you are quoted, because "we will just give the warehouse team comment access" is exactly the kind of assumption that produces a surprise renewal.

The structural point: records grow with time, seats grow with headcount. Airtable charges you for both. Self-hosting charges you for neither, and charges you for something else instead.

What Does 180,000 Records Actually Look Like?

People underestimate how fast a real ops base fills up, because they count the thing and forget the children of the thing.

One load in a brokerage base is not one record. It is a load record, two to four stop records, one to three document records, and if you are doing it properly, a status event log with a row per check call, per status change, and per document upload. A brokerage running 40 loads a week generates roughly 2,000 loads a year and somewhere in the range of 15,000 to 25,000 child records on top, depending on how granular the event log is.

Three years of that and you are through the Team cap. Add a status event table with any real granularity and you are looking at the Business cap inside five years. E-commerce has the same shape: orders are fine, but order line items, fulfillment events, and returns are what fill the base. Home services teams hit it through job records plus photos plus time entries.

The escape hatches on Airtable are real but they cost you something:

• Archive to a second base. Cheap and easy. You lose cross-year reporting inside Airtable, and you now maintain two schemas that drift.
• Delete the event log. Fastest fix. You give up the audit trail, which is the exact thing you want when a claim shows up nine months later.
• Shard by year. Works. Every automation, interface, and integration now needs to know which base to talk to.
• Upgrade to Enterprise Scale. Solves the record problem. Introduces a procurement conversation and a per-seat number you have to negotiate rather than look up.

None of these are unreasonable. They are just work, and that work is a real cost that belongs in the comparison alongside the subscription.

What Does the Same Data Cost on NocoDB Self-Hosted?

NocoDB self-hosted is the Community Edition, open source under AGPL, free to run with unlimited users and unlimited records. The practical limit is whatever your database can handle, and Postgres handles a few hundred thousand rows without noticing.

What you actually pay for is infrastructure. A realistic small-business setup, using current published rates:

• Application server: a 4 vCPU / 8 GB shared instance runs around €8 to €9 per month before VAT at Hetzner as of mid-2026. Equivalent specs at DigitalOcean or Vultr land closer to $40 to $50 per month, so the provider choice matters more than the software choice here.
• Database: DigitalOcean managed Postgres starts around $15 per month for a single node with 1 GiB of RAM. Adding a standby for high availability roughly doubles the primary cost, so a modest HA pair sits closer to $60 per month. Running Postgres yourself on the same box is $0 and is a decision you should make deliberately, not by default.
• Attachment storage: object storage on S3, R2, or Spaces. At the volumes an SMB generates, roughly $5 per month is a fair placeholder, and R2-style zero-egress pricing helps if documents get pulled frequently.
• Backups and monitoring: somewhere between $0 and $20 per month depending on whether you use the provider's snapshot service, your own dumps to object storage, or a hosted monitoring tool.

Lean end, self-managed Postgres on a single Hetzner box with off-box backups: roughly $30 per month, about $360 a year. Comfortable end, separate managed HA Postgres and a bigger app instance: roughly $100 to $120 per month, about $1,200 to $1,450 a year.

Notice what is missing from that list. The record count appears nowhere. Going from 50,000 records to 500,000 changes your storage bill by a rounding error and may push you up one database tier. That is the entire structural argument for self-hosting, and it is a real one.

Worth knowing: NocoDB also sells a hosted cloud product with a free tier that caps around 50,000 records and paid tiers in the range of roughly $10 to $25 per seat per month, plus quoted enterprise self-hosted editions that add SSO, audit logs, and row-level security. Self-hosting the Community Edition is one path, not the only one.

The Line Item That Kills Naive Comparisons

Here is where most self-hosting posts stop, and it is where they become dishonest. A $30 hosting bill is not the total cost of running NocoDB self-hosted.

You now own: OS patching, NocoDB version upgrades and the occasional breaking change, TLS certificate renewal, database backups, and more importantly backup restore testing, which nobody does until the first time they need it. You own query performance when a table crosses a few hundred thousand rows and somebody built a view with no supporting index. You own the pager at 6am on a Monday when dispatch cannot log in.

Put a number on it. If that work costs two to four hours a month and you value that time at $75 to $125 per hour fully loaded, you are adding roughly $150 to $500 per month in labour. Against an eight-seat Airtable Business bill of about $360 per month, the infrastructure savings can be entirely consumed by the maintenance.

That is not an argument against self-hosting. It is an argument about where the crossover sits. The math flips clearly in favour of self-hosting when at least one of these is true:

• You are past 15 editors. Twenty editors on Business billed annually is roughly $900 per month, about $10,800 a year. At that level a few hundred dollars of monthly maintenance is obviously the better trade.
• You are well past 125,000 records and the alternative is an Enterprise Scale quote plus a sharding project.
• You already run servers. If you have a VPS, a deploy pipeline, and somebody who is comfortable with Docker and Postgres, the marginal maintenance cost of one more service is much smaller than the numbers above.
• You need people in the data who are not worth a seat. Subcontractors, warehouse staff, seasonal drivers. Unlimited users is the feature you are actually buying.

Migration Reality: What Moves and What Breaks

The data is the easy part. Export to CSV or pull through the API, import into NocoDB, done in an afternoon for a mid-sized base. Everything else is the project.

Moves with minor cleanup: tables, text, number, date, currency, checkbox, single and multi select fields, and links between tables if you rebuild the relationships deliberately rather than trusting an importer to infer them.

Needs rewriting by hand: formulas, rollups, and lookups. The concepts exist on both sides but the syntax and the evaluation behaviour differ. Budget for reading every formula field and testing the output against known records, not for a find-and-replace.

Needs a script with retry logic: attachments. Airtable's API attachment URLs are time-limited rather than permanent, so you cannot simply copy the link into your new system. You download the file and re-upload it to your own object storage, then rewrite the reference. At a few hundred attachments this is an afternoon. At 20,000 it is a job that will fail partway through and needs to be resumable.

Does not migrate at all: automations, Interfaces, the scripting extension, and any marketplace extensions. There is no import path. Automations get rebuilt in n8n, Make, or NocoDB webhooks. Interfaces get rebuilt as NocoDB views and shared views, which is a real functional downgrade and the single most common reason a migration stalls halfway.

Breaks quietly: record IDs. Every external system holding an Airtable record ID stops matching. Your Make scenarios, your QuickBooks sync, your carrier portal, your customer-facing forms. The fix is to keep a mapping table of old ID to new ID during the cutover and to remap systematically, not to discover each one when it fails in production.

Realistic timeline for a base with 10 to 20 tables, 30 to 50 automations, and a handful of interfaces: plan in weeks, not in a weekend. Run both systems in parallel for at least two weeks with writes going to the new system and the old one kept read-only, so you have somewhere to check when a number looks wrong.

Where Airtable Genuinely Wins

Interfaces are the strongest argument for staying, and it is not close. Building a clean, permissioned, role-specific screen for a dispatcher who should never see the whole table is straightforward in Airtable and is meaningfully more work in NocoDB. If your operation depends on those screens, migrating means either rebuilding them or accepting a worse experience for the people doing the actual work.

The second argument is who does the building. An ops manager can build a functioning Airtable base without an engineer. That capability disappears the moment your database is a self-hosted service with a deploy process, and the cost of that shows up as every small change now going through a queue.

Third, the boring things. Uptime is somebody else's problem. Support has a phone number. Compliance paperwork exists on the higher plans if a customer asks for it. Sync from external sources is available on Business and above. If you are three or four people under 50,000 records, Team at roughly $20 per seat is around $60 to $80 a month, which is genuinely cheap, and no honest reading of the numbers supports migrating away from it.

The plainest version: if you are not near a cap and not near a headcount jump, this whole comparison is a distraction from work that would actually make you money.

Where NocoDB Self-Hosted Genuinely Wins

The cost stops tracking your growth. That is the headline, and for a business whose record count compounds every year it is the argument that matters most over a five-year horizon.

Underneath it, NocoDB sits on your own Postgres. That means your operational data is queryable with SQL, joinable against everything else you keep, and directly pointable from a BI tool or a reporting job without an API sync in the middle. Anyone who has built reporting on top of an Airtable base and then rebuilt it after a schema change understands the value of this.

For Ontario businesses with customers who ask where data lives, self-hosting also gives you a straightforward answer on residency. You choose the region, you control the backups, and PIPEDA questions become a configuration decision rather than a vendor questionnaire.

Be clear about what you give up: a smaller extension ecosystem, weaker interface tooling, upgrades that are your responsibility, and an AGPL license that has real implications if you plan to embed the product in something you distribute to customers. Read the license before you build a customer-facing portal on it.

The Middle Path Most Teams Should Consider First

Before a full migration, there is a cheaper move that solves the record problem without touching the seat problem or the interface problem.

Keep Airtable as the working surface for open, active records only. Push closed loads, shipped orders, or completed jobs to a Postgres database nightly, and delete them from the base after a verification window. Point reporting at Postgres. Your base stays comfortably under the cap indefinitely, your team keeps the Interfaces they use every day, and you now have a real database holding your history that you can query properly.

That setup costs roughly $15 to $40 per month in database and sync infrastructure plus a build. It also happens to be the exact groundwork you would need for a full migration later, so it is not wasted work if you eventually decide to move.

The inverse hybrid also works: NocoDB self-hosted over Postgres as the system of record for the bulk of your data and your unlimited users, with a small Airtable base retained for the two or three people who genuinely need Interfaces. You pay for a handful of seats instead of all of them.

How to Decide

Four questions, in order, with actual thresholds rather than principles.

1. How many editors will you have in 18 months? Under 5, stay on Airtable. Between 5 and 15, run the numbers with your own labour rate. Over 15, self-hosting or a hybrid is very likely cheaper.
2. What is your record growth per year, including child records? If you will cross 125,000 in a single base within three years, you are choosing between sharding, an Enterprise Scale quote, and migrating. Pick deliberately now rather than under pressure later.
3. Who patches the server? If there is no honest answer to this, self-hosting will cost you more than the subscription, in outages rather than dollars. Managed hosting for NocoDB or the middle-path archive setup is the better move.
4. How many Interfaces are load-bearing? Count the screens that a non-technical person uses daily. If that number is more than three or four, the migration cost is much higher than the data suggests, and the hybrid is the realistic option.

The comparison people expect is a feature grid. The comparison that decides it is your seat count, your record growth curve, and whether anyone on your team will actually test a database restore. Answer those three honestly and the choice usually makes itself.

← Back to Blog