Supabase cloud cost vs self-hosted Supabase

Which cost components move when you self-host Supabase

This table sets each Supabase Cloud cost component against the matching self-hosted cost, and marks whether it is one-time or recurring. Read the commercial column for what the plan bundles and the self-hosted column for what you buy, run and staff yourself. The main takeaway is that self-hosting removes the subscription line but moves compute, backups, upgrades and on-call time onto your own budget.

What moves the comparison most

Six inputs decide whether self-hosted Supabase costs less than Supabase Cloud for your workload. Most of them change the answer in both directions, so model each one against your own usage before comparing invoices with infrastructure and staff time.

Which managed features you rebuild and which you go without

How to build the comparison with your own numbers

This sequence turns Supabase Cloud invoices and your own load data into a side-by-side cost model that covers both recurring and one-time costs. The output is a worksheet you can take to finance and to a quote request.

1. Export twelve months of Supabase Cloud invoices

   Finance or the account owner downloads the invoices for the last 12 months and lists every line item: per-project compute, disk, monthly active users, egress, point-in-time recovery, Team plan seats and any add-ons. Keep the plan name and billing period beside each line so that changes in plan or usage are visible. The step is done when every month is accounted for and each line can be traced to a project and an owner.

2. Map each line to a self-hosted component

   The platform owner pairs each Supabase Cloud line with the self-hosted cost it replaces, such as a compute host for Postgres, disk for the database and Storage volumes, egress from your network, and backup tooling for the features that PITR and managed backups provided. Mark the lines that have no self-hosted equivalent, including branching, managed backups, PITR and the Management API, as gaps. The output is a two-column table with a gap column that someone must sign off on.

3. Size servers from the documented minimums and your load tests

   Start from the minimum requirements in Supabase's Docker self-hosting guide, which are 4 GB RAM, 2 CPU cores and a 40 GB SSD, and the recommended 8 GB RAM, 4 cores and 80 GB. Then run load tests against a staging copy using your real query patterns, peak connections and Storage traffic to find the size you need. Remove services you do not use, such as Realtime or imgproxy, as the guide allows. The output is a sized environment for production and staging, with the test results attached.

4. Price backup tooling and object storage with your provider

   Because managed backups and PITR are not available when self-hosting, the infrastructure lead prices the replacement: database dump or WAL archiving tooling, an off-site backup target, retention storage and any monitoring that alerts on failed jobs. Price Storage object storage separately, since Supabase Storage objects must be kept in a store you run or rent. Ask your cloud or data center provider for written rates for compute, block storage, object storage and outbound transfer. The output is a line-item quote for each component.

5. Estimate upgrade and on-call hours for your team

   The platform lead estimates recurring operating time for upgrades, security patches and on-call coverage, based on how often the Docker configuration and its pinned service versions change in your environment. The Supabase changelog flags security fixes and one-way Storage database migrations that require a backup before updating, so each release needs a test in staging and a rollback plan. Community support means your team carries the troubleshooting that a paid plan would otherwise cover. The output is an hours-per-month estimate by role, reviewed by the team that will be on call.

6. Add one-time migration and rebuild costs

   The project lead lists one-time costs separately from recurring ones: the migration itself, rebuilding features you will not carry over, hardening and secret setup, and testing. Use Supabase's documented platform-to-self-hosted path as the migration scope and confirm with a implementation partner or internal team what the effort involves. Record these costs once, so that they do not inflate the recurring monthly comparison. The output is a one-time cost sheet with the assumptions written beside each figure.

7. Request written quotes and confirm current plan terms

   Ask Supabase in writing for the current pricing and Team or Enterprise terms that apply to your projects, since plan features and fees change, and check the public pricing page before you rely on any figure. Request written quotes from your infrastructure provider and from any implementation partner, based on the same written scope so that the numbers are comparable. The sequence is complete when the worksheet shows recurring cost, one-time cost, gaps and assumptions, and each figure cites its quote or invoice.

What recurring work starts after you switch

Costs teams forget on each side

Hosted Supabase bundles operations into the plan fee, and self-hosting moves that work to your team. The cards below cover the items that tend to surface only after cutover, on both sides of the comparison, so you can price them before committing to either path.

Common questions about Supabase self-hosting costs

What a migration adds to the one-time budget

What to put in a written quote for self-hosting

A quote for self-hosting Supabase should follow a fixed sequence, from an inventory of what you run today to a tested restore and a handover, so that each cost line maps to a deliverable you can check. The order matters because sizing, backup design and support terms all depend on what the current project actually uses.

1. Inventory the current Supabase Cloud project

   Start by listing what the project uses: Postgres schema and row volume, Auth users and providers, Storage buckets and object counts, Edge Functions, Realtime channels, custom domains, and the Supabase features you rely on today, such as branching, PITR or daily backups. The inventory is produced jointly by your team and the implementation partner, and it is done when every feature is marked as carried over, rebuilt or dropped. Ask the vendor for your current plan and add-ons so the comparison reflects what you pay for now.

2. Define the target architecture

   Describe where the self-hosted stack will run, including the cloud account, data center or air-gapped network, the number of environments, how traffic reaches Kong or the Envoy gateway, and how Studio access is restricted. The quote should name each service in the Docker Compose stack that will run and any services you will remove because they are unused. It is complete when a diagram and a service list have been reviewed and signed off by your security and platform owners.

3. Size compute, storage and network

   Sizing turns the inventory into hardware or cloud instance requirements for Postgres, Storage, Realtime and the other services. Supabase's self-hosting guide gives minimum and recommended starting points, which the quote should treat as a baseline to be checked against your actual load. Ask for the sizing assumptions in writing, including growth and peak concurrency, and for the egress and disk figures that drive recurring infrastructure costs.

4. Design backup and a tested restore

   Self-hosted Supabase does not include managed backups or point-in-time recovery, so the quote must cover what replaces them: database dumps or WAL archiving, Storage object backups, retention periods set by you, and where copies are stored. The step closes only when a full restore has been run into a separate environment and the result has been checked against row counts, Auth user counts and sample Storage objects. Ask for the restore runbook and the recorded results, not just a description of the backup job.

5. Write the upgrade runbook

   Docker configuration releases bundle specific upstream versions of Auth, PostgREST and Realtime, and some changes are one-way, such as Storage database migrations that require a backup before updating. The runbook should cover how a release is staged in a non-production copy, how the backup is taken first, how rollback is handled, and who approves production changes. Ask for the runbook to be tested on a staging copy before the first production upgrade, and for the test record to be delivered with it.

6. Hand over and document the system

   Handover covers the deployed environment, secrets and JWT key handling, access accounts, monitoring and alerting, the backup and upgrade procedures, and a list of known gaps against the hosted features. Your team should run at least one restore and one upgrade with the partner present so that ownership is shared, not assumed. The step is complete when your engineers can perform the routine operations from the documentation alone.

7. Agree support terms in writing

   Community support is the default for self-hosted Supabase, so a quote should state what extra support you are buying, if any: response expectations, who handles on-call, how incidents are escalated, and whether upgrades and continuous testing are included as a retainer. DeployOpen scopes engagements in writing before work starts and does not publish a price list, so the quote follows from this written scope. Ask for every support, security patch and upgrade item to be a named line with its own deliverable.