Supabase Pricing vs Running Postgres on Your Own Server

A Supabase project that is mostly a Postgres database costs $25 a month on the Pro plan until it outgrows the 1 GB Micro compute. After that, the compute add-on is the bill: a dedicated 8 GB database is $160 a month once you add typical disk and egress, and a 32 GB one with 2 TB of egress is about $757. The same Postgres on a Hetzner server with the same RAM costs $51 and $164.

I learned this the hard way on a different platform. On Railway I was paying over $500 a month, and most of it was the database: it was hit hard and used a lot of gigabytes. Today one dedicated server at €80 a month runs everything I have. So this article is for people in that spot: you use Supabase as a Postgres database, maybe with auth, and the bill keeps climbing.

Prices checked 2026-10-01. Every Supabase price below links to Supabase's own pricing page or docs.

Supabase pricing calculator: what would your bill be?

This calculator prices Supabase Pro against the same database on a Hetzner Cloud server. Pick the compute size you run now; if your database is too big for that size, it moves up to the smallest size Supabase recommends for it. The server column picks the cheapest Hetzner server with at least the same RAM and a disk twice the size of your database, so dumps and vacuum have room.

How much does Supabase cost per month?

Supabase has four plans: Free at $0, Pro from $25 a month, Team from $599 a month, and Enterprise at a custom price (Supabase pricing). The plan fee is per organization. On top of it you pay for compute per project, plus disk, egress and monthly active users beyond the included amounts. For a database-heavy app, the plan fee is the small part. The compute add-on is where the money goes.

Sources: pricing page, billing docs.

What does the Supabase Pro plan include?

The Supabase Pro plan is $25 a month and includes $10 of compute credits, which pays for one project on the Micro size (1 GB RAM, shared CPU). It also includes an 8 GB disk per project, 250 GB of egress, 250 GB of cached egress, 100,000 monthly active users, 100 GB of file storage, 7 days of daily backups, and projects that never pause (Supabase pricing).

Spend caps are on by default on Pro. With the cap on, you can't go past the included quotas. Turn it off and every overage below starts billing.

Sources: pricing page, disk, egress, MAU.

How much do Supabase compute add-ons cost?

Supabase compute runs from $10 a month for Micro (1 GB RAM, shared CPU) to $960 for 4XL (64 GB, 16 dedicated vCPUs), billed hourly per project (compute and disk docs). The $10 credit comes off the total, so on Pro a Small costs you $5 extra and a Large costs $100 extra. Every size has a recommended maximum database size, so a growing database pushes you up the table even if your traffic doesn't.

The jump from Small to Medium is the one that hurts. You pay four times as much ($15 to $60) for twice the RAM, and you still share the CPU. Large is the first size with dedicated cores. Each extra project gets its own compute, so a staging project on Micro adds $10 a month (compute billing).

Why is my Supabase bill higher than $25?

A Supabase bill goes past $25 for four common reasons: you moved off Micro compute, your disk grew past 8 GB, your egress passed 250 GB, or you have more than one project. Disk is billed on provisioned size, not used size (disk docs), and on Pro the disk grows by 50% automatically when it hits 90% full (database size docs). So you pay for headroom.

Egress catches people too. Database egress counts: every row your API returns is egress, alongside auth, storage, realtime, Edge Functions and the connection pooler (egress docs). A chatty API that returns big JSON payloads can burn through 250 GB faster than you'd expect.

The last one is backups. Daily backups are included, but point-in-time recovery costs $100 a month for 7 days, $200 for 14 and $400 for 28, and it needs at least the Small compute size (PITR docs, backup docs).

What does Supabase cost for a small, medium and large app?

Here are three worked bills. Small is a side project on Micro. Medium is a busy SaaS on a dedicated 8 GB database. Large is a 100 GB database on 2XL with real traffic. Supabase wins the small one. From medium up, the Hetzner server with the same RAM costs a third or less, before counting the work you take on.

Small: 5 GB database, Micro, 50 GB egress, 10,000 MAU

Netcup is the other provider I'd look at, and often the better deal: its VPS 500 (2 vCPU, 4 GB RAM, 64 GB SSD, traffic included) is €8.26 a month incl. VAT on a 12-month term, with datacenters in Europe and Manassas in the US (netcup VPS plans).

Medium: 40 GB database, Large, 600 GB egress, 80,000 MAU

Large: 100 GB database, 2XL, 2,000 GB egress, 150,000 MAU

Hetzner prices are from the 15 June 2026 price adjustment (Germany/Finland, USD, excluding VAT and IPv4) and IPv4 pricing. Included traffic is 20 TB on CCX13 and 30 TB on CCX33 in the EU (Hetzner General Purpose).

I matched RAM and dedicated cores, which is generous to Supabase. A shared Hetzner CX43 with 16 GB of RAM is $18.49 and would run the medium database fine for most apps. And for the large one, a dedicated server like the €80 box I run everything on beats any cloud server.

What do you give up by moving Postgres off Supabase?

You give up everything Supabase runs around Postgres. Supabase Auth, Storage, Realtime, Edge Functions and the auto-generated REST API all live next to your database, and Auth keeps its users in the same Postgres. Move the database and those come with you only if you replace them. You also give up the managed parts: daily backups, PITR, automatic disk growth, the connection pooler, Postgres upgrades and the Studio dashboard.

Concretely, this is the list I'd check before moving:

• Auth. If you use Supabase Auth, you need a replacement such as Better Auth or Auth.js in your app, and a migration for existing users. Row Level Security policies that call auth.uid() need rewriting.
• Data access through supabase-js. Calls like supabase.from("posts").select() go through Supabase's REST API. Without it, you query Postgres from your server with an ORM or SQL.
• Storage and Realtime. Files move to S3-compatible object storage. Realtime needs its own replacement, or polling.
• Backups. Supabase takes daily backups for you. On your own server, nobody does unless you set it up. More on that below.
• Upgrades and disk. You decide when to upgrade Postgres, and you watch the disk. A full disk on your server stops writes the same way it does on Supabase.

If you use Supabase only as a Postgres URL with an ORM in front, most of this list doesn't apply. That's the reader this article is for.

How do you back up Postgres on your own server?

Run pg_dump on a schedule from a different machine and copy each dump to object storage in another place. That gives you a daily snapshot you can restore, which is roughly what Supabase's included daily backups give you. Test a restore once a month. A backup you never restored is a guess. If you need recovery to the second, that's WAL archiving with a tool like pgBackRest or WAL-G, which is more work.

Here is the version I'd start with. It runs on a second machine (a small VPS or anything with cron) that can reach the database over a private network or an SSH tunnel:

#!/usr/bin/env bash
# /usr/local/bin/pg-backup.sh
set -euo pipefail
stamp=$(date -u +%Y-%m-%dT%H%M)
file="/var/backups/app-$stamp.dump"

pg_dump --format=custom --no-owner "$DATABASE_URL" > "$file"
aws s3 cp "$file" "s3://my-db-backups/postgres/" --endpoint-url "$S3_ENDPOINT"
find /var/backups -name 'app-*.dump' -mtime +7 -delete

# crontab -e on the backup machine: every night at 03:15 UTC
15 3 * * * /usr/local/bin/pg-backup.sh >> /var/log/pg-backup.log 2>&1

And the restore you should actually practice, into a scratch database:

pg_restore --clean --if-exists --no-owner -d "$SCRATCH_DATABASE_URL" app-2026-10-01T0315.dump

Three things matter more than the script. The dump leaves the database server, so losing the server doesn't lose the backups. The bucket has a lifecycle rule that deletes old dumps, so you don't pay forever. And something tells you when the job fails; a dead cron job looks exactly like a working one until the day you need it.

A server-level disk snapshot (Hetzner sells these for 20% of the server price, per its billing FAQ) is a nice extra, but a snapshot of a running Postgres isn't a substitute for pg_dump.

How do you move a database from Supabase to your own server?

Take a pg_dump of your schemas from Supabase using the direct connection string in the dashboard, restore it into Postgres on your server with pg_restore, then point your app at the new URL. For a small database that's minutes. For a busy one, plan a short maintenance window so no writes land on Supabase after the dump. Keep the Supabase project for a week before deleting it.

If you only use the public schema, dump only that one with --schema=public. The auth and storage schemas belong to Supabase's services and won't do anything on a plain Postgres.

Is Supabase worth it?

I think Supabase is worth it while you use what it bundles and while you fit on Micro or Small. At $25 to $30 a month you get Postgres, auth, storage, backups and a dashboard, and no server to look after. It stops being worth it when you use it as a Postgres URL and the compute add-on is most of the bill. That's the point where you pay $100 to $400 a month for RAM that costs $50 to $160 on a server you rent.

The markup is the price of not running a server. My opinion is that this price only goes one way from here: as AI gets better at the boring server work, paying a platform three to five times the hardware cost makes less and less sense.

Should you stay on Supabase or move Postgres to your own server?

Stay on Supabase if:

• Your project fits the Pro plan on Micro or Small and the bill is $25 to $40.
• You use Supabase Auth, Storage or Realtime heavily and don't want to replace them.
• Nobody on the team wants to own backups and Postgres upgrades.
• You need point-in-time recovery and don't want to run WAL archiving yourself.

Move Postgres to your own server if:

• You're on Medium compute or bigger and use Supabase mostly as a database.
• Egress or MAU overages are a big line on the bill.
• You already run your app on a server, so the database can sit next to it on a private network.
• You're willing to set up the backup job above and test a restore.

I build Ployz, which runs this setup on a server you rent, and it's free on your own servers. Its one-click Postgres is a plain Postgres service with a volume, not a managed database: Ployz doesn't back it up, so the backup job above is still yours to run.