Supabase for free: hosted, local or self-hosted

Supabase has a free hosted tier, an open-source stack you can run on your own machine or server, and a local development stack the CLI starts in Docker. All three can cost nothing, but they ask for different amounts of time and carry different risks. The useful question is not whether Supabase is free, but which part of it you are willing to operate. Here are the options as Supabase and the competing projects describe them today.

What does the free hosted plan include?

The pricing page gives the Free plan two active projects. Each project gets 500 MB of database space, and the plan includes 1 GB of file storage and 5 GB of egress. It also gives you 50,000 monthly active users, unlimited API requests, 500,000 Edge Function invocations, and 2 million Realtime messages with up to 200 peak connections. For a small project those limits are workable: a brochure site, an internal tool or a prototype will usually fit. A product with image uploads or a chatty API will meet storage and egress first.

The part people miss is pausing. Supabase pauses Free projects that show low activity over a seven-day period. The docs say a few database requests a day are usually enough to stay awake, and that the owner gets a warning email about a week before the pause and a confirmation when it happens. A paused project stops answering requests and keeps its data. To restore it, open the dashboard, choose the organization and the paused project, and press Resume project. The body of that page gives a one-year restore window, while one heading on the same page still says 90 days, so plan for the shorter period and keep an independent backup. Paid projects are not paused for inactivity.

Two smaller limits matter in practice. Edge Functions have their own invocation allowance, and Realtime has a connection ceiling, so a tool that holds a socket open for every visitor is a different proposition from one that queries on demand. The free tier is generous for a prototype and thin for anything with steady traffic.

Is Supabase open source, and what does self-hosting include?

The main supabase/supabase repository declares the Apache-2.0 licence. Self-hosting is an official path, and the self-hosting guide calls Docker Compose the fastest and recommended way to do it. A self-hosted deployment is one Supabase project, not a multi-tenant platform: the guide says Studio does not support multiple organizations or projects, and that most settings come from environment variables.

The Docker guide names what runs. An Envoy API gateway sits in front, with Kong available as an override. Behind it are Auth, PostgREST, Realtime, Storage, Edge Runtime, postgres-meta and Studio, over a single Postgres instance with Supavisor pooling connections. imgproxy, Logflare and Vector are optional and add resource use. The gateway listens on port 8000, and in production a reverse proxy such as Caddy or Nginx terminates TLS on 443 in front of it. The stated minimum is 4 GB of RAM, 2 cores and 40 GB of SSD, with 8 GB, 4 cores and 80 GB recommended.

Then comes the part that decides whether self-hosting is cheap or expensive. Supabase lists what the operator owns: server provisioning and maintenance, security hardening and operating system updates, service configuration, Postgres maintenance, high availability and scaling, backups and disaster recovery, and monitoring. You generate the keys and secrets, set the public URLs and configure SMTP for auth email, and the docs warn against starting with the example defaults. Self-hosted Supabase is community-supported. Several platform features are managed-only: branching, advanced metrics beyond logs, managed backups and point-in-time recovery, analytics and vector buckets, ETL and the Management API. In exchange, the stack does not phone home or collect telemetry, and the data stays on hardware you control.

That is the trade in one sentence: the hosted free tier hands you a running project in minutes, and self-hosting hands you control in exchange for becoming the operator.

Can I run the whole stack locally for free?

Yes, and this is the option we use most. The local development guide starts everything with npx supabase start once the CLI is installed. The CLI page gives the npm package as supabase, installed with npm install supabase --save-dev, and also documents Homebrew and pnpm. You need a container manager compatible with the Docker API; the guide names Docker Desktop, OrbStack, Rancher Desktop and Podman. Studio comes up at http://localhost:54323.

The local stack uses no project quota and costs nothing beyond your machine. It works offline, keeps test data local and lets you reset the database without asking anyone. It is the right place for development, migrations, integration tests and small personal tools. It is not a production host. The guide warns against exposing it and shows how to bind it to 127.0.0.1 on an untrusted network, and the docs describe a CLI-started Postgres as not production ready. With default ports, one local project runs per machine; several at once is an experimental supabase stack feature on Linux and Apple silicon macOS.

How does Supabase compare with PocketBase, Appwrite and Nhost?

These three projects compete for the same job, a backend you can start for free, and each makes a different bet.

PocketBase is an MIT-licensed Go backend that ships as one file. It embeds SQLite and bundles an admin dashboard, user authentication with email and password plus OAuth2 providers, file storage with optional S3-style backends, realtime subscriptions and a REST API. You extend it with Go and JavaScript hooks. The difference is the shape of the system: PocketBase is one process and one embedded database, which is simple to run and to copy, while Supabase is Postgres plus a set of services you can scale and split. If you need Postgres extensions or a database server you can connect to with ordinary SQL tools, PocketBase is not that.

Appwrite is BSD-3-Clause and calls itself the open-source cloud for agents and developers. It bundles authentication, databases, file storage with image transformations, serverless functions, realtime events, sites and messaging. It is designed for self-hosting, with Docker, Kubernetes and marketplace installs, and a self-hosted instance can be configured with the same features as the cloud. The database is Appwrite's own API, with managed PostgreSQL and MySQL offered alongside it, so the model is a broad platform rather than a thin layer over Postgres you already know.

Nhost is MIT-licensed and describes itself as the open-source Firebase alternative with GraphQL. It bundles a Postgres database with an instant GraphQL API, authentication, storage served through a CDN, JavaScript or TypeScript serverless functions, and bring-your-own containers. Its self-hosting page lists a community edition, a supported self-hosted option and a dedicated cluster. Architecturally it is the closest to Supabase, because both put Postgres and its extensions at the centre and add auth, storage and functions around it. The difference is the API you program against: GraphQL first, rather than PostgREST and the Supabase client libraries.

A fair summary: PocketBase when one small binary and SQLite are enough, Appwrite when you want a broad platform you can also host, Nhost when you want Postgres with GraphQL, Supabase when you want Postgres with a large ecosystem and a managed free tier. None of them is free in the sense of no work. Each moves the work somewhere else.

What about managing several local Supabase projects?

Our own Supabase Local Manager exists for that narrow case. It is an independent project, not affiliated with, endorsed by or sponsored by Supabase, Inc., and it is in early access with private source code; access is requested through GitHub. The site states GPL-3.0-or-later. One Node and Express service provisions and manages many local Supabase stacks at once, and each project reserves a block of 11 ports from the 60000 band. A path-routed front door on port 6000 and a subdomain proxy on port 9000 give each project a stable entry point. The Supabase CLI handles the basic database management, and the manager adds the services, APIs and frontend a full Supabase stack needs, so the whole stack runs locally from one place. It needs Docker. The dashboard covers tables, SQL, row-level security with a policy test sandbox, auth users, storage, functions, logs, migrations, backups, advisors and API documentation.

It manages local stacks, not a hosted service. Running a stack for other people is the self-hosting job described above, with the backups, TLS and monitoring that implies. The product's scope will be confirmed on release.

Which option should a small team choose?

Start on the hosted Free plan while you validate an idea or build an internal tool, and treat pausing as part of the deal. Move to the CLI stack when you need repeatable development or several projects side by side. Self-host when data location, compliance or long-term cost justify the operational work, and budget for a person who can own backups and updates. Look at the alternatives when your architecture already points towards GraphQL or away from Postgres. If you are choosing for a client project and want a second opinion, our custom software work starts from the same question, and you can book a free intro call.