Self-Hosting Supabase Won't Save You Money on Local Dev (and What Will)

Every few weeks someone in a Supabase Discord asks the same question: "Should I self-host to save money?"

The answer depends on which problem they're actually trying to solve. About half the time, what they mean is "the hosted free tier is too small for my side project." The other half, they mean "I want to run this on my laptop without paying for a cloud project." Those are different problems, and self-hosting only solves one of them.

This post is the honest breakdown: what self-hosted Supabase really is, when it's the right call, and why for local dev and previews you probably want something much smaller.

What "self-hosted Supabase" actually means

Supabase is not one server. The official self-hosting path is Docker Compose, and it starts PostgreSQL plus ten services around it: PostgREST, GoTrue for auth, Realtime, Storage, Studio, the API gateway, the Supavisor pooler, imgproxy, the meta service, and the edge runtime. Eleven containers, and a quiet instance idles at around 2 GB of RAM before the database has a working set.

Then there's the part the quickstart glosses over: the default .env ships demo secrets and a dashboard password literally named this_password_is_insecure_and_should_be_updated. Every key has to be regenerated before you put real data in it. After that you own TLS termination, SMTP for auth emails, backups that you've actually tested restoring, and image upgrades across all eleven services.

None of that is a criticism. It's a full production backend, and self-hosting it is a real, supported path. Supabase's own docs frame it as suitable for small-to-medium production workloads. But it's ops work, and it's community-supported rather than covered by a support plan.

When self-hosting is the right call

• Data residency. You need the database in a specific jurisdiction or on hardware you control.
• Cost at scale. Once you're paying for compute add-ons, a dedicated box can be cheaper, if you have someone to run it.
• Extensions or config the hosted platform doesn't allow.
• You already run infrastructure and adding eleven containers to it is Tuesday.

If none of those apply, the hosted platform's free tier and $25/mo Pro plan are almost always cheaper than the hours you'll spend on Compose.

When self-hosting is the wrong tool

Here's the case that trips people up: you want a backend on your laptop, in CI, or per preview environment.

Self-hosting doesn't help there. You'd be running the same eleven containers, just on your own machine, which is exactly what supabase start already does. On a 16 GB laptop it's tolerable. On the 8 GB machine most students and indie devs actually own, it's the reason they stop before writing a line of app code. And in CI, spinning up that stack on every pull request is the slowest job in the pipeline.

This is a different problem from production hosting, and it wants a different shape of solution: not "run all of Supabase yourself," but "run enough of Supabase, in one process, wherever you are."

The third option: one process

That's what tinbase is. An open-source (MIT), Supabase-compatible backend that runs as a single process with no Docker:

npx tinbase start

That boots embedded native Postgres 17 with RLS, plus REST (PostgREST grammar), Auth (GoTrue-shaped), Storage, Realtime, in-process Edge Functions, and a Studio-style dashboard. The official @supabase/supabase-js works unchanged. It reads your existing supabase/migrations/*.sql and supabase/seed.sql.

The numbers from the README, against the Docker-based local stack:

	Supabase local (Docker)	tinbase (native engine)
Processes	12 containers	2
RAM at boot	~1.4 GB	~59 MB
Cold boot	~1 min	~2 s

There's also a WASM engine (PGlite) that runs the whole backend inside a browser tab, and an ultralight pure-JS engine for previews. Same handlers, different database underneath.

What tinbase is not

This is the part I'd rather say now than have you find out later.

tinbase is alpha, built for local dev, CI, prototypes, and embedded use. It is not a self-hosted Supabase and not a production database. Specifically:

• Single connection. Writes serialize. Fine for one developer or one preview; not for concurrent users.
• Coverage is roughly 80% of the supabase-js surface. MFA, SSO, phone auth, and pgvector aren't there yet. The gaps are listed in the repo's coverage table.
• Realtime DELETE events aren't filtered per row the way INSERT and UPDATE are.
• Edge Functions with npm: or jsr: imports still need bundling.

If your question is "how do I host my production Supabase myself," tinbase is the wrong answer. Use Docker Compose, regenerate every secret, set up backups, and read the self-hosting docs twice.

The decision, compressed

You want to…	Use
Ship to production with zero ops	Supabase hosted
Ship to production on your own hardware or region	Self-hosted Supabase (Docker Compose)
Run a backend on a laptop, in CI, or per preview	tinbase (or supabase start if RAM is no object)
Run a backend inside a browser tab	tinbase WASM engine

The migration files are the same across all four rows. That's the whole point: develop against the small one, deploy to the big one, and never edit app code in between.

Try it

npx tinbase start

Source, roadmap, and the coverage table are on GitHub. If you hit a supabase-js call that doesn't work, open an issue; those reports are what move the table.

Which row are you in? I'm curious how many people asking "should I self-host" are actually in row three.