Per-Seat SaaS vs Self-Hosted Postgres: The Arithmetic Nobody Runs Honestly

The invoice that grows every time you hire

Per-seat pricing is the most elegant business model a software vendor ever designed, and the least comfortable one a growing team ever signs. You are not buying a tool. You are renting a multiplier attached to your headcount. Hire an operations analyst, bring on three contractors for a quarter, let the finance team into the workspace so they stop asking for CSV exports, and the invoice moves before the value does.

At eight people this is invisible. At fifteen it shows up in a budget review. At fifty someone in finance circles the line item and asks the question that brings you to an article like this one: could we just run this ourselves on Postgres?

The answer is sometimes yes and often no, and the difference is not ideological. It is arithmetic. Most articles on this subject put a $8,100 annual subscription next to a $60 server, declare a 96 percent saving and stop there. That comparison is not merely optimistic, it is wrong in a way any engineer who has actually operated a database will spot in four seconds. This piece runs the honest version.

Every vendor price below was read on the publisher's own pricing page on 10 August 2026. Nothing here is estimated, extrapolated or remembered.

How these tools actually bill, which is not how people describe it

Airtable

Airtable charges $20 per seat per month on the annual commitment for Team, and $24 if you pay monthly. Business is $45 per seat per month annually, $54 monthly. The monthly premium is 20 percent, which is the vendor pricing your optionality.

Now the rule that most comparison articles get wrong, and it matters more than the headline rate: Airtable bills only the users who hold edit rights on at least one base in the workspace. Collaborators with read-only access are not billed. People submitting through a form are not billed. Anyone consuming a share link is not billed.

Run that against a real company. A forty-person business where twelve people build and maintain bases and twenty-eight people read dashboards and submit forms is a twelve-seat bill, not a forty-seat bill. If you have been quoting yourself the forty-seat number in internal debates, you have been arguing against a phantom, and the case for migrating is materially weaker than you thought. Before you scope any migration, open the billing page and count actual editors. That single audit is the cheapest way to find out whether there is a case at all, and it often ends the discussion before any technical objection is raised.

Notion

Notion Business sits at $20 per user per month billed annually, $24 monthly. Same structure as Airtable Team, same annual discount shape. The difference is that Notion's value concentrates in documents and knowledge rather than structured records, which changes what a Postgres migration would even replace. Migrating a Notion wiki to a database is not a migration, it is a rewrite of how your company writes things down. Keep those two conversations separate.

Monday.com

Monday lists Basic at $9, Standard at $12 and Pro at $19 per seat per month on the annual plan, with a three-seat minimum. That floor is the detail nobody mentions. A two-person team pays for three. It is trivial money at that size, but it tells you the pricing is designed around team growth, not individual adoption, and the same design philosophy shows up in every tier above.

Smartsheet

Smartsheet Pro is $9 per user per month, and the plan is capped at ten members. That ceiling is the real constraint, not the rate. Pro is not a plan you scale on, it is a plan you graduate from. We are deliberately not quoting the Business tier here: the figure circulates under two different values across sources we checked, and publishing a number we cannot confirm on the vendor's own page would undermine every other number in this article.

Annual cost by team size

List prices, annual commitment, twelve months, no discounts negotiated. The last column is a private server in Europe, which is a flat line: it does not move when you hire.

Team size	Airtable Team	Airtable Business	Notion Business	Monday Pro	Smartsheet Pro	Private EU server
3 seats	$720	$1,620	$720	$684	$324	€180 to €540
5 seats	$1,200	$2,700	$1,200	$1,140	$540	€180 to €540
10 seats	$2,400	$5,400	$2,400	$2,280	$1,080	€180 to €540
15 seats	$3,600	$8,100	$3,600	$3,420	Plan capped at 10 members	€180 to €540
25 seats	$6,000	$13,500	$6,000	$5,700	Plan capped at 10 members	€180 to €540
50 seats	$12,000	$27,000	$12,000	$11,400	Plan capped at 10 members	€180 to €540

Read the shape, not just the totals. Every SaaS column is a diagonal line. The server column is horizontal. That is the entire structural argument for self-hosting, and it is real. It is also, on its own, not sufficient to justify anything.

What a private server in Europe actually costs in 2026

Public list prices, read on 10 August 2026. These are market reference points, not our prices.

Provider and plan	Listed price per month	Resources	Note
Hetzner CX23	€5.49	2 vCPU, 4 GB RAM	Shared vCPU, fine for a small internal tool
Hetzner CAX11	€5.99	ARM entry instance	Postgres runs well on ARM, check your extensions first
Hetzner CCX13	€42.99	Dedicated vCPU	Was €15.99 before the June 2026 increase
Scaleway PLAY2-PICO	around €4.99	1 vCPU, 2 GB RAM	Development and staging only
Scaleway PLAY2-MICRO	around €14	4 vCPU, 8 GB RAM	Realistic small production tier
OVHcloud VPS-1	€7.60	Entry VPS	€3.50 before 1 April 2026

Two of those prices doubled this year, and that is the story

Look at the note column. Hetzner's CCX13 went from €15.99 to €42.99. OVH's VPS-1 went from €3.50 to €7.60 on 1 April 2026. These are not promotional expiries, they are structural repricing.

The cause is upstream of the hosting industry entirely. Memory got expensive. DRAM pricing rose roughly 30 percent against late-2025 levels because AI data center construction is absorbing global DRAM and NAND supply faster than fabs add capacity. Server memory and server SSDs are the same commodities that go into training clusters, and the clusters outbid everyone. Hosting providers who had held prices flat for years passed the increase through in 2026.

The practical consequence for you: any migration business case built on today's hosting price needs a sensitivity check. If your entire justification survives only while the server costs €15 a month, it is not a business case, it is a bet on a commodity market. Build the case at a price two or three times the current one and see whether it still holds. Ours does, because the flat line beats the diagonal one long before the flat line's height matters. Yours might not. Any article that quotes a hosting price without telling you it moves is going to age badly, and probably already has.

The comparison everyone runs, and why it is dishonest

Here is the seductive version. Airtable Business, 15 seats: 45 × 15 × 12 = $8,100 per year. A decent European server: €15 to €45 a month, so €180 to €540 a year, regardless of how many people use it. Put those side by side and the conclusion writes itself.

Except that the $8,100 is not buying a database. Postgres is free. The $8,100 is buying everything wrapped around it, and a bare rented server delivers exactly none of it.

Capability	In the per-seat subscription	On a bare rented server	Who owns it after migrating
User interface: grids, forms, views, filters	Yes, and it is most of what you pay for	None	You build it, then you maintain it forever
Automated backups with tested restores	Yes	Snapshots exist as a paid option you must configure	You, including the restore drills nobody runs
High availability and failover	Yes on business tiers	A single VPS is a single point of failure	You, and it changes the server budget
Someone on call when it breaks at 2 a.m.	Yes, at the vendor's stated SLA	Nobody	You, or someone you contract in writing
Per-user and per-record access control	Yes, configured in a UI	Roles and row-level security exist, unwritten	You write and test every policy
OS and database security patching	Not your problem	Entirely your problem	You, every month, indefinitely

Comparing $8,100 to a few hundred euros without naming those six rows is not a saving, it is a transfer of unpriced obligations onto your own team. Your reader knows it. Your CFO will find it. Say it out loud and the rest of your argument becomes credible.

The only calculation that matters

Forget the 96 percent. The real question has three parts, in order, and you have to answer all three:

• One. Does the subscription you stop paying fund building the interface that replaces the one you are giving up?
• Two. Does it then fund maintaining that interface, year after year, as your processes change?
• Three. Does it then fund operating the server: patching, backups, restore tests, monitoring, and a human who answers when it is down?

The saved subscription is your budget line. Whether it covers all three depends entirely on scope, and scope is the thing you establish in writing before anyone touches a schema. An article that skips this question is worth nothing, and a vendor who skips it is selling you a project, not a solution.

When we tell people not to migrate

This is the part of the conversation that actually saves money, so it goes before the part where we describe what we do.

• Your real editor count is small. Under roughly ten billed editors, on Airtable Team or Monday Standard, the annual subscription is a rounding error next to any custom build. Stay. Revisit at twenty-five.
• Your workspace changes weekly. The genuine superpower of these tools is that a non-engineer restructures a workflow on a Tuesday afternoon without filing a ticket. If your operations still move that fast, a custom interface will slow you down and you will resent it by month three. Migrate systems that have stopped changing shape.
• Nobody owns the server afterwards. If the plan ends at "we will figure out backups later", the plan is to lose data later. An unowned Postgres instance is worse than an expensive subscription, and it fails at the worst possible moment.
• You are migrating Notion documents. Wikis, meeting notes and specifications are not relational records. Moving them into Postgres solves a billing problem by creating a writing problem. Different project, different justification.
• The motivation is annoyance, not economics. Being irritated by a vendor is a real feeling and a terrible business case. If the numbers do not hold at the current seat count, they do not hold.

When the numbers do hold

The migration tends to pay when several of these are true at once: you are past twenty-five billed editors and hiring; the core workflow has been stable for over a year; you are already hitting per-base record limits, attachment quotas or API rate limits and reaching for the next tier to escape them; you need joins, transactions or reporting the tool cannot express and you are compensating with fragile automations; and someone credible will own the server in writing rather than in spirit.

Note the pattern: the strongest cases are rarely about price alone. Price is what opens the conversation. Hitting the product's ceiling is what closes it.

Where the data sits, and why that argument reads differently in Austin than in Bengaluru

Airtable, Notion and Smartsheet are American companies, and so are the managed Postgres platforms usually proposed as the destination. monday.com is the exception in that list: the company is headquartered in Tel Aviv, Israel, and listed on Nasdaq. Those are facts about corporate domicile, not accusations. Using an American SaaS product is entirely lawful and hundreds of thousands of competent teams do it every day.

What changes with geography is which consequence of that fact you care about.

If your team and customers are in the United States, hosting in Europe is not a compliance win. It is a control decision and a cost decision. Control means your schema, your backups and your export path belong to you, so a pricing change, an ownership change or a discontinued tier is an inconvenience rather than an emergency. Cost means European providers list some of the cheapest usable compute on the market, which is why they appear in the table above. The trade-off is honest and physical: a transatlantic round trip has a latency floor set by fiber routing and the speed of light, and no amount of tuning removes it. That floor is irrelevant for a form submission and very relevant for a chatty grid that issues a request per cell. If your workload is chatty and your users are all in one US time zone, put the machine near the users. The arithmetic in this article does not change, only the flag on the data center.

If your team is in India, two things bite harder. First, per-seat pricing is denominated in dollars and does not index to local salary levels. A $45 seat is the same $45 in San Francisco and in Pune, while the payroll sitting next to it is not. The ratio of tool spend to headcount spend is structurally worse outside the highest-wage markets, which is why this question surfaces earlier in Indian engineering organisations than in American ones. Second, if you build for European or British clients, those clients increasingly ask where their data physically lives, and the GDPR framework does impose specific obligations on transfers of personal data outside the EU. Being able to answer "in Frankfurt, on a machine we administer" removes a procurement obstacle. That is a commercial argument, not a legal threat.

Why we do not point you at a managed Postgres

The obvious escape hatch from per-seat billing is a managed Postgres platform. Supabase and Neon are the names that come up, they are genuinely good products, and both are American companies. Choosing one means you have swapped a per-seat subscription for a usage-based subscription and kept every structural dependency that made you uncomfortable: someone else's pricing page, someone else's roadmap, someone else's ownership. A managed service can reprice, change hands or retire a tier, and you inherit the change on their timeline.

We say this from the position of people who did it. Go To Agency left Vercel and Supabase in June 2026 and moved onto our own European server. Our production runs there. We sell what we operate, which is why our recommendation is a Postgres instance on a private machine in Europe that we administer, and not a resold managed plan with our logo on the invoice.

None of which means the Supabase skills stop mattering. Postgres is Postgres. Schema design, row-level security policies, migration discipline and connection pooling are the same craft whether the instance is managed or yours, and that craft is exactly what our Supabase and Postgres engineering work covers. The platform changes. The database does not.

What actually breaks when an Airtable base becomes a Postgres schema

Moving the rows is the easy hour. Here is what consumes the real time, roughly in order of pain:

• Formula and rollup fields. These are computed columns with no schema of their own. Each becomes a generated column, a view or application logic, and someone has to decide which, field by field. This is usually the largest single chunk of work and it is almost always underestimated.
• Linked records. They look like foreign keys and are not. Airtable links are many-to-many by default, and an export gives you the primary field text rather than a stable record id, so duplicate or renamed values produce references Postgres will refuse outright. Expect to find data that was never actually valid.
• Attachments. Files live on vendor infrastructure behind expiring URLs. They need to be pulled, stored in object storage you control, and re-referenced before anything expires.
• Views, filters and grouping. Every saved view is a query plus a UI state. Postgres gives you the query for free and none of the UI.
• Automations and integrations. Each one is a small piece of undocumented business logic that someone built and forgot. Inventory them before, not after.
• Permissions. A UI toggle becomes a row-level security policy you write and then test. This is where migrations quietly leak data if nobody is rigorous.

Downstream of the schema you need an API layer, because a database with no interface is not a tool. That is standard API and backend engineering: REST or GraphQL, an OpenAPI schema, authentication, pagination, rate limits. And if the replacement is a genuine internal product rather than a set of admin screens, it is a product build with product concerns like multi-tenancy and role modelling, which is the ground covered by our SaaS development work. Teams that would rather own the code in-house sometimes just need the capacity, in which case hiring full-stack developers onto the existing team is the cheaper structure.

A one-week decision protocol

You do not need a consulting engagement to answer this. You need five days and some discipline.

• Day 1. Open the billing page. Count actual billed editors, not headcount. Multiply by the real annual rate. That number is your entire budget, and it is often smaller than the one in your head.
• Day 2. List every formula field, rollup, linked-record relationship, automation and integration. The length of that list, not the row count, predicts the migration effort.
• Day 3. Ask which parts of the workspace changed shape in the last six months. Those parts are not migration candidates yet.
• Day 4. Name the person or contract that will own patching, backups, restore tests and incident response. If the name is blank, stop here and stay on the subscription.
• Day 5. Recompute the case with hosting priced at three times today's rate. If it still holds, it is robust to the memory market. If it does not, you were betting on DRAM prices.

All vendor pricing in this article was read on the publishers' own pricing pages on 10 August 2026. Hosting prices moved twice in 2026 and will move again. Verify before you commit a budget.