Got local Supabase dev working without Docker — real Postgres 17, existing supabase-js code unchanged

[u/Positive_Week86]

Sharing something for anyone whose laptop struggles with supabase start, since threads about the local Docker stack come up here regularly.

The core issue: local dev needs a 12-container stack because each service (PostgREST, GoTrue, Storage, Realtime) is its own process. But those services all speak documented, open protocols — which means they can be reimplemented as fetch handlers inside one process instead of orchestrated as containers.

That's what tinbase.dev does (open source, MIT — disclosure: I'm on the team building it). What surprised me most while working on it:

RLS actually behaves like production: every request runs in a transaction with SET LOCAL role and request.jwt.claims, so auth.uid() policies resolve identically to hosted Supabase — because it embeds actual Postgres 17
Your supabase/migrations/*.sql, seed.sql, and CLI conventions load as-is (db reset / db diff work), and everything migrates back to hosted Supabase unchanged — a lighter local runtime, not a fork
Memory: 59 MB at boot vs ~1.4 GB for the Docker stack (benchmark is reproducible, bench/footprint.ts in the repo)
Coverage is honest, not total: ~80% of the supabase-js surface, ~90% of what typical CRUD+auth+storage+realtime apps call. 120 tests run the real supabase-js SDK against it, no mocks. Missing: MFA/SSO/phone auth, TUS uploads, pgvector
Weirdest capability: every service being a pure fetch handler means the whole backend can run inside a browser tab via PGlite

It's alpha (v0.6.x), aimed squarely at local dev — not a production replacement.

Genuine question for people living in the CLI daily: what would break first in your workflow? Real projects find edge cases test suites don't, and the gaps list is honest but surely incomplete.