Is Supabase free? Cloud limits vs self-hosted

Is Supabase free?

Supabase is free in two different ways, and the two are not the same offer. The hosted Free plan costs no money and asks for no card. The source is open, so running the whole stack on your own VPS (virtual private server) costs nothing to license. One of them bills you in limits. The other bills you in work.

Checked on 10 September 2026, supabase.com/pricing lists a Free plan with 0.5 GB of database, 1 GB of file storage, 5 GB of egress and 50,000 monthly active users, across two active projects. The same page carries the line that decides most of this: "Free projects are paused after 1 week of inactivity". Re-check those figures before you plan around them, because pricing pages move.

What the Free plan actually gives you

[
  {
    "plan": "Free",
    "db_gb": 0.5,
    "file_storage_gb": 1,
    "egress_gb": 5
  },
  {
    "plan": "Pro",
    "db_gb": 8,
    "file_storage_gb": 100,
    "egress_gb": 250
  }
]

MAU (monthly active users) counts the distinct users who authenticate inside a billing month, so 50,000 is generous for anything you are still building. The user count is almost never what runs out first. It is the 0.5 GB of Postgres, or the 5 GB of egress once you start serving images or files out of Storage.

Two active projects is the quieter limit. One production project and one staging project fill the Free plan by themselves, so a third idea either waits or shares a database with something it should not share with.

Why the pause matters more than the storage limit

"Free projects are paused after 1 week of inactivity" is the sentence that ends most free-plan plans. A project nobody queries for seven days stops serving requests. A demo linked from a README, or a staging API you touch once a month, is down at the moment the person you sent it to clicks the link. Restoring it is a button in the Supabase dashboard, so the repair is quick, but only if you are watching.

That is the real price of the hosted free tier. You are not paying money. You are paying with availability, and with a ceiling you cannot raise without moving up a plan.

What Pro and Team cost when Free runs out

[
  {
    "plan": "Free",
    "usd_per_month": 0
  },
  {
    "plan": "Pro",
    "usd_per_month": 25
  },
  {
    "plan": "Team",
    "usd_per_month": 599
  }
]

Pro starts at $25 per month and includes 8 GB of disk per project, 100 GB of file storage and 250 GB of egress. Past those amounts the page prices disk at $0.125 per GB, file storage at $0.0213 per GB and egress at $0.09 per GB, all as of 10 September 2026. Pro also removes the inactivity pause. Team starts at $599 per month and is priced for organizations that need the compliance and access-control features, not for one developer with a side project.

Spend caps are on by default on the Pro plan. That default matters: crossing an included quota restricts the service rather than growing the invoice while you sleep. Turn the cap off and you have chosen the other failure mode on purpose. This is the same arithmetic you run when you weigh a managed Postgres bill against a VPS you run yourself, because the managed price is mostly buying someone else's on-call rota.

What self-hosting costs instead

Nothing in licence terms. The Supabase documentation calls Docker Compose "the fastest and recommended way to self-host", and the stack runs on an ordinary VPS. The bill arrives as work instead, and the docs are direct about which work becomes yours:

• server provisioning and maintenance
• security hardening, and keeping the OS and services updated
• service configuration and management
• Postgres database maintenance
• high availability and scalability
• backups and disaster recovery
• monitoring and uptime

Read that as a weekly cost, not as a setup cost. Provisioning happens once. Updates and backup checks happen forever. If your honest answer is that nobody will ever test a restore, the hosted plan is cheaper than it looks, because a restore you have never run is not a backup.

What self-hosted Supabase does not include

The self-hosted stack is not a copy of the hosted platform. The docs name what is unavailable: "branching, advanced metrics beyond logs, managed backups and PITR, analytics and vector buckets, ETL, and the platform management API". PITR (point in time recovery) is the one people miss after they migrate. On the hosted plans it is a setting you switch on. On your own box it is a base backup plus WAL (write ahead log) archiving, plus somewhere off the server to keep both, plus a rehearsal that proves the pieces fit together. Tools such as pgBackRest exist for exactly this, and the configuration is yours.

Studio, the web dashboard, "doesn't support multiple organizations or projects" when self-hosted. One stack is one project. So if escaping the two-project limit was your reason to self-host, plan on a second stack on its own ports or its own box, rather than a second project inside one dashboard.

What you get back

Self-hosted Supabase "does not phone home or collect any telemetry", in the words of the documentation. Your rows and your user table sit on hardware you rent directly, which is the whole argument when a client contract or a regulator names the country the data has to stay in.

You also get the Postgres itself. The hosted platform tunes and manages the server for you. On your own box, shared_buffers, max_connections, the extension list and the pooler in front of it are all yours to set. That last piece bites early, because a serverless function or a busy application will open more connections than Postgres will hold, and that is the point where running PgBouncer or Supavisor on your own VPS stops being optional.

Egress is the ceiling self-hosting removes most visibly. 5 GB disappears quickly once Storage is serving images or audio to real visitors. Most VPS plans include transfer measured in terabytes, so a file-heavy app hits the hosted ceiling long before it strains the server. If Storage is the reason you are reading this, price the disk before the compute: what a terabyte really costs on block or object storage decides more of the total than the CPU does.

Starting the self-hosted stack

The documented path is a shallow clone of the repository's docker directory, pinned to a self-hosted release tag. As of 10 September 2026 that tag is self-hosted/v0.8.1. An official setup script exists at supabase.link/setup.sh, and the manual clone below is the better choice when you want the file tree in your own git repository.

git clone --depth 1 --branch self-hosted/v0.8.1 https://github.com/supabase/supabase
mkdir supabase-project
cp -rf supabase/docker/. supabase-project
cd supabase-project && cp .env.example .env
sh utils/generate-keys.sh
docker compose pull
sh run.sh start

sh utils/generate-keys.sh is the step you cannot skip. .env.example ships with placeholder secrets that anyone can read in the public repository, so a stack started on those values is open to whoever finds the port. Set DASHBOARD_PASSWORD in .env as well, because Studio is protected by HTTP basic authentication, and the docs require that password to contain at least one letter.

Check the result with docker compose ps, which should list every service as running or healthy, then open Studio on port 8000 and sign in with the dashboard credentials. sh run.sh secrets prints the generated keys when you need them again, and sh run.sh stop shuts the stack down. Do not publish port 8000 straight to the internet: put a reverse proxy with TLS (transport layer security) in front of it, or keep it on a private network. The full walkthrough, including that proxy and the .env values worth changing first, is in the step by step guide to self-hosting Supabase with Docker Compose.

Which free is right for you

Pick the hosted Free plan while the project is being built rather than used, and while a pause costs you nothing. It is a genuine plan with a generous user count. It is also a plan that expects you to graduate from it.

Pick Pro at $25 per month once the project has users who notice downtime. That is less money than the hours you would spend on backup checks in a single month, so paying it is a scheduling decision rather than a defeat.

Pick self-hosting when you already run a VPS and already do the operator work on it for something else, when the data is not allowed to leave your jurisdiction, or when your storage and egress figures grow faster than a server's price does. The trade repeats across every open core product. The split between n8n's free community edition and its paid tiers and the split between the free Nextcloud Hub and its enterprise subscription draw the same line in the same place. The free software is complete enough to carry a real workload. The paid product sells you the part nobody enjoys owning.

FAQ

Is the Supabase free plan free forever?

The Free plan has no time limit and no card requirement, checked on 10 September 2026. It has limits instead: 0.5 GB of database, 1 GB of file storage, 5 GB of egress, 50,000 monthly active users and two active projects. What ends free use for most people is not a quota at all. It is the rule that "Free projects are paused after 1 week of inactivity".

What happens when a free Supabase project is paused?

It stops serving requests. API calls fail and the dashboard marks the project as paused until someone restores it, which is a button in the Supabase dashboard. Your application gets no warning of its own, so a demo you shared a month ago is usually already down by the time somebody tells you. If the project has to answer at any hour of any day, move it to Pro or self-host it.

Is self-hosted Supabase the same as the hosted version?

No. The documentation lists what self-hosting does not include: "branching, advanced metrics beyond logs, managed backups and PITR, analytics and vector buckets, ETL, and the platform management API". Studio also "doesn't support multiple organizations or projects", so one self-hosted stack means one project. The database, auth, storage, realtime and edge function components are the same software the hosted platform runs.

Does self-hosted Supabase send anything back to Supabase?

No. The self-hosting documentation states that a self-hosted deployment "does not phone home or collect any telemetry". The containers pull their images from a public registry when you run docker compose pull, which is an ordinary image download and not a report about your data. Everything after that stays on your server, which also means every backup and every security update is on you.