Skip to content
Go To Agency
Go To Agency

Moving off Airtable onto PostgreSQL, once the numbers say it pays

Airtable bills every editor seat, every month, whether that person builds automations or fixes one typo a quarter. We count the seats that genuinely edit, put the real cost next to the real replacement cost, and tell you plainly when the answer is to stay where you are.

Send us your seat count →
Everything in writing, no callsReply within 24 working hoursPostgreSQL on a private server in Europe

The bill grows with your team, not with your usage

A base starts as a spreadsheet someone shared. Two years later it runs a hiring pipeline, a client tracker and three automations, and the invoice has quietly become one of the larger line items in the department. Nothing broke and nobody made a bad decision. The pricing model simply charges for people rather than for work, so the cost climbs every time somebody new needs edit rights, even if they touch one field a month.

45 dollars
Airtable Business, per seat per month on annual billing
8 100 dollars
The same plan at fifteen editor seats, over twelve months
Edit rights
What triggers a billed seat, read-only access does not

Four steps in this order, and the second one can stop everything

Count the seats that actually edit, not the accounts

Before any technical decision, find out what you really pay for. Airtable bills users who hold edit rights on at least one base in the workspace. Read-only collaborators are not billed, and neither are form submissions or share links. Plenty of published comparisons get this wrong and inflate the platform's cost. A team that handed out the editor role for convenience is paying seats for people who only ever read. That inventory sometimes lowers the bill without migrating anything, and it changes the arithmetic of everything that follows.

Put the calculation in two columns, never one

On the left, what you pay now: the published seat price times the number of editor seats, times twelve. On the right, the target cost, which is not just server rent. It includes hosting, monitoring, backups with a restore you have actually tested, and building the interface your team currently gets for free. That last item is the one most migration pitches leave out, and it is usually the largest.

Model the data properly rather than copying the tables

An export gives you rows. It does not give you the linked records, the rollups, the formula fields recalculating on read, or the views each team relies on. Those are the parts that break silently. We model them explicitly in PostgreSQL before moving a single row, because discovering a missing relationship after cutover means rebuilding under pressure.

Rebuild only the interface people actually use

Nobody uses every view. We watch what the team opens, rebuild those screens, and leave the rest behind. A migration that reproduces the whole workspace costs several times what it needs to and delivers screens nobody misses.

What we commit to, and what we do not claim

< 24h
Reply to your brief
In writing
Scope settled before we start
Private server in Europe
Hosting
Always
Schema and data exportable at any time

Three scopes, all quoted after we have seen the workspace

Cost review

On quote
  • Seat inventory: who edits, who only reads
  • Two-column calculation against your published plan
  • Written verdict, including stay put if that is the answer
  • No migration commitment
Send us your seat count →
Recommended

Migration

On quote
  • Relational model built from your bases
  • Linked records, rollups and formulas modelled explicitly
  • Interface rebuilt for the views your team really opens
  • Backups with a restore tested before cutover
  • PostgreSQL on a private server in Europe
Send us your seat count →

Migration and automations

On quote
  • Everything in the migration scope
  • Existing automations rebuilt outside the per-seat model
  • Integrations reconnected one by one
  • Written handover documentation
Send us your seat count →

The full calculation, its counterpart, and the cases where you should stay

Migration pitches tend to show one column: what you pay today. That column is easy and it always looks damning. The honest version has two, and the right-hand one is longer than people expect. Here is what goes in it, and where the argument for moving falls apart.

What the per-seat bill was also buying

Fifteen editor seats on the Business plan comes to 8 100 dollars over twelve months at the published rate. Set against a server, the gap looks overwhelming. It is not, because that money was also buying an interface that non-technical people can use without training, hosting that somebody else keeps running, backups that exist whether or not anyone thought about them, and a permissions model that already works. Rebuilding those is the right-hand column, and on a small team it can exceed the saving outright. This is the part a migration pitch has every incentive to leave out, and it is the reason we run the review as a separate scope with no commitment attached.

A hosting price that moves, and why it moves

Server pricing is not the fixed point people assume. Providers reprice, and they reprice upwards: one instance we regularly quote nearly tripled in a single move in June 2026. Any calculation that treats hosting as a constant for the next three years is wrong on its face. We quote what it costs today, name the provider, and say plainly that this line can move. It is still far more predictable than a seat count that grows every time you hire, but predictable is not the same as fixed, and pretending otherwise would be the same sleight of hand we are asking you to watch out for.

Where the data lives now, where it would live, and when to stay

Your data currently sits with a vendor under its own terms and jurisdiction. After a migration it sits in a PostgreSQL database on a private server in Europe, in a standard format any competent team can pick up. That matters for procurement in some organisations and not at all in others, so we do not oversell it. What we will say without hedging is when to stay. If you have fewer than roughly ten editor seats, the saving rarely covers the rebuild. If your team depends on the vendor's mobile app, there is no equivalent worth building. If nobody internally will own a database once we hand it over, do not migrate, because an unowned database becomes a liability within a year. If the calculation does not come out clearly in favour, our written answer is to stay where you are.

There is no universal threshold, which is exactly why we put the calculation in two columns. What we can say is what drives it: the number of people holding edit rights, how much of the interface has to be rebuilt, and how many automations depend on the platform. A team of five editors almost never justifies a migration. A team of thirty, with most of them only reading, usually gets a bigger saving from an access review than from a migration.

No, and this is where most comparisons go wrong. Airtable bills users who hold edit rights on at least one base in the workspace. Read-only collaborators are not billed, and neither are form submissions or share links. If a comparison multiplies your headcount by the seat price, it is overstating the platform's cost. Other vendors count differently, so the inventory has to be done against your own contract terms.

The things that were never in the rows. Linked records become plain text identifiers with nothing on the other end. Rollups and lookups stop existing, because they were computed on read rather than stored. Formula fields disappear. Attachments become URLs that expire. Views, filters and the permissions attached to them have no equivalent in a CSV. An export is a starting point for a migration, never a migration.

Because a managed platform reintroduces the dependency you are leaving. You would swap per-seat billing for per-usage billing on someone else's terms, with the same exposure to a pricing change. A private server has a fixed cost you can read in a contract, and the database is standard PostgreSQL that any competent team can take over. The honest trade-off is that you become responsible for backups and updates, which is precisely why they are in the scope rather than left to you.

The method does not. The numbers do. Each vendor defines a billable user differently, and some count viewers where Airtable does not. So the first step is the same, reading your own contract terms rather than a comparison article, and the two-column calculation follows from whatever those terms say. Tell us which tool you are on and we will run it against that grid.

What else we build

React Development AgencyHire Full-Stack Developers Who Actually ShipWebsite Redesign AgencyAPI Development Agency

Related services

Marketing websiteWebsite redesignWeb application
See all our services
4.9/5 sur 35 avis clientsRead what our clients say

Send the seat count and a screenshot of your plan

Tell us how many people hold edit rights, which plan you are on, and roughly what the workspace does. You get a written two-column calculation back within 24 working hours, including the case for staying if that is what the numbers say. No call, no meeting.

Get the calculation →
Free quote →
Airtable to PostgreSQL migration | Go To Agency