Supabase self-hosted vs cloud: when self-hosting saves money and when it doesn't

The honest answer to "Supabase self-hosted vs cloud" is this: self-hosting saves money only when your bill is driven by usage that a single server you control can absorb, and when someone on your side will own backups, upgrades and security every month. If neither is true, Supabase Cloud is usually the cheaper choice once you count your time and your risk, even if the invoice looks bigger.

Most founders who ask this question built their app with Lovable, Bolt, Cursor, Replit or v0, watched the Supabase bill climb, and read that Supabase is open source and can run on your own server. All of that is true. What the forum threads skip is the list of jobs that quietly move from Supabase's team to yours the day you leave the cloud. This post walks through that list, gives you a decision test you can run in an afternoon, and explains when we recommend a move on our self-host Supabase page and when we tell people to stay put.

What actually changes when you self-host Supabase

Supabase publishes an official self-hosting guide, and the common path is Docker Compose: Postgres, the Auth server, the REST layer (PostgREST), Realtime, Storage, the API gateway and Studio run as containers on a machine you rent. The code is the same family of open-source projects the cloud runs. The difference is who operates it.

Jobs that move to you

• Backups and restores. On the cloud, daily backups are part of paid plans, and point-in-time recovery is available as an add-on. Self-hosted, there are no backups unless you build them, store them off the box, and test restoring them.
• Upgrades. Postgres versions, Supabase container images and the operating system all need patching. Some upgrades need a planned maintenance window.
• Security of the box. Firewall rules, SSH access, TLS certificates, and making sure Studio and the database port are not open to the internet. The default Docker setup protects Studio with a username and password you must change; leaving the example values is a real and common mistake.
• Secrets. You generate the JWT secret and the anon and service keys yourself. If they leak or stay at example values, anyone can mint tokens for your project.
• Email for Auth. Sign-up confirmation and password reset emails need your own SMTP provider.
• Monitoring. Disk filling up, memory pressure and a container that silently restarts are now yours to notice.

Things that stay the same

Your Row Level Security policies, your tables and your app code mostly move over unchanged. A self-hosted project is not more secure by default. If your RLS was open on the cloud, it is open on your server too. Before any migration, run the free self-check so you are not copying a leak to a new home.

When self-hosting Supabase usually saves money

Self-hosting tends to pay off when the cost driver is raw usage rather than features. Patterns we see:

1. Steady, predictable traffic. An internal tool, a CRM, or a B2B app with a known number of daily users fits comfortably on one well-sized server. 2. Egress-heavy apps. If your bill is dominated by bandwidth (images, file downloads, chatty realtime), a server provider with generous included transfer can change the math. Our earlier post on Supabase egress cost shows how to read those lines first, because sometimes the fix is a cache, not a move. 3. Several small projects. Agencies or founders running many small Supabase projects sometimes consolidate them onto infrastructure they control. 4. Data residency or ownership requirements. A client contract may require data on servers you manage in a specific region. 5. You already have someone who runs servers. If a teammate patches Linux boxes for a living, the added work is small.

When it does not save money

Self-hosting is often the wrong call when:

• Your bill is high because of a bug. A query running in a loop, a missing index, or a realtime subscription on every row will cost money anywhere. Fix it first; then compare.
• You rely on managed features. Point-in-time recovery, read replicas, branching and the managed dashboard experience either need real work to replicate or are not part of the self-hosted stack in the same form.
• Nobody owns the box. A server nobody patches is a liability that grows each month. The savings disappear the first time a disk fills at 2 AM and the app is down until morning.
• Traffic is spiky and unpredictable. A launch, a viral moment or seasonal peaks are easier on a managed platform than on a single fixed server.
• You are still changing the product every day. Early on, your time is worth more than the bill difference.

The self-host decision test (run it in an afternoon)

This is the test we use before recommending a move. Write down an answer for every step; vague answers are a "not yet".

Step 1: Split your bill into lines

Open the Supabase billing page and write each line separately: compute, database size, egress, storage, monthly active users, and any add-ons. Note which line grew fastest over the last three invoices.

Step 2: Ask whether the growth is real usage or waste

For the fastest-growing line, find the cause. Egress: which bucket or endpoint? Compute: which queries? Use the Supabase query performance report and advisors. If you find a fix that removes most of the growth, stop here. You do not need to move.

Step 3: List the managed features you actually use

Write down: backups (and whether you have ever restored one), point-in-time recovery, branching, read replicas, Edge Functions, Realtime, Storage image transformations, Auth providers. Each one you use is a job to rebuild or replace on your own server.

Step 4: Name the owner

Write the name of the person who will patch the server, read alerts and run restores. If the answer is "the AI" or "we will figure it out", self-hosting is not ready.

Step 5: Price the whole picture, not just the server

Add up the server, off-site backup storage, an SMTP provider, monitoring, and the hours your owner will spend each month. Compare that to your current bill after the fixes from Step 2.

Step 6: Rehearse the move

Restore a copy of your database to a test server, point a staging copy of your app at it, and sign in with two different test accounts. Check that each user still sees only their own data and that file uploads still work.

Step 7: Plan the way back

Write how you would return to the cloud if the move goes badly. A migration with no rollback plan is a bet, not a plan.

If you pass all seven steps, self-hosting is likely to save you money. If you fail Step 2 or Step 4, fix those first.

A safer middle path

You do not have to pick one extreme. Options between "stay exactly as is" and "move everything":

• Fix the expensive lines on the cloud first, then re-measure for a full billing cycle.
• Move only the heavy part. Large file storage can sometimes sit on cheaper object storage while the database stays managed.
• Self-host staging or internal tools first to build the muscle before moving production.
• Keep the database managed, own everything else. Own your repo, your domain and your environment variables so a later move is easy. Our older post on what self-hosting Supabase includes covers the full component list.

Founder takeaways

• Self-hosting is an operations decision first and a cost decision second.
• Fix waste before you move; a bug costs money on any server.
• Every managed feature you use becomes a job you own.
• No named owner means no move.
• Rehearse the migration and the rollback before touching production.

FAQ

Is self-hosted Supabase the same as Supabase Cloud?

It is built from the same open-source projects, but some platform features work differently or need extra work, and operations become your job. Check the official self-hosting docs for the current component list before planning.

Is self-hosted Supabase more secure?

Not by default. Your RLS policies move with you, and you add new risks such as an exposed Studio, default secrets or an unpatched server. It can be very secure, but only if someone maintains it.

Can I move back to Supabase Cloud later?

Usually yes, because it is Postgres underneath. Moving back is far easier if you planned it before leaving, which is why Step 7 matters.

How long does a migration take?

It depends on database size, Storage use, Auth setup and how much downtime you can accept. A rehearsal on a test server is the most reliable way to estimate it for your app.

---

If you want a second opinion before you move, start with our self-host Supabase review. Book a free technical assessment and we will look at your bill lines, the features you depend on and who would own the server, then tell you plainly whether self-hosting saves money for your app or whether a few fixes on the cloud will do more.