Spots

Running Real Postgres Locally Without Docker (with Tinbase)

Docker Supabase on an 8 GB laptop: 12 containers, ~1.6 GB RAM idle, 45 s cold boot Tinbase: one ~58 MB binary, real Postgres 17, ~100 MB RAM idle, ~2.5 s cold boot supabase-js works with zero code changes: swap one env var Migrate an existing project with supabase db dump | tinbase import RLS, edge functions, and realtime use the same contract as hosted Supabase Not for you if you live in the Supabase dashboard or need Storage image transforms

Disclosure: I work on Tinbase. It's MIT-licensed and

Disclosure: I work on Tinbase. It's MIT-licensed and not affiliated with Supabase. It matches the supabase-js client contract, it's not a Supabase replacement.

Most of us run local Postgres via Docker

Most of us run local Postgres via Docker. On an M1 Air with 8 GB RAM, the Docker Supabase stack eats 1.6 GB of RAM at rest and takes 45 seconds to cold boot. That's a lot of headroom to give up for a dev environment, and it's brutal in CI or on a workshop laptop.

Tinbase is a single binary that runs real

Tinbase is a single binary that runs real Postgres 17 plus Supabase's auth, realtime, and edge-function layers. Here's the whole setup, start to finish. Windows: grab the .exe from the releases page. Single binary either way. Boot time: ~2.5 s cold, ~800 ms warm. supabase start is ~45 s cold on the same machine. Verify it's real Postgres

Not PGlite (Postgres compiled to WASM with the

Not PGlite (Postgres compiled to WASM with the client-server pieces cut out). Not SQLite with a Postgres wire adapter. Actual Postgres 17. Any existing Supabase project works by changing one env var:

Same client, same auth flow (supabase.auth.signInWithPassword), same realtime

Same client, same auth flow (supabase.auth.signInWithPassword), same realtime subscriptions, same RLS. For a typical Next.js + Supabase codebase the migration is one env var plus one dump/import. Migrate an existing Supabase project From your existing Docker Supabase project:

If you rely on Supabase-specific extensions or hooks

If you rely on Supabase-specific extensions or hooks that Tinbase doesn't support yet, tinbase import prints a warning listing each one. The current compatibility matrix is in the import docs, so check that before you commit an afternoon to it. Enable anything else the normal way: Because it's real Postgres, RLS policies work exactly as they do on hosted Supabase. This is the piece I trust most:

auth.uid() is provided by Tinbase's auth layer and

auth.uid() is provided by Tinbase's auth layer and matches the Supabase contract. If your policies pass locally against Tinbase, they pass in hosted Supabase. Tinbase runs edge functions in an embedded V8 (not a Deno subprocess). Cold start is ~15 ms. Same HTTP surface as Supabase Edge Functions, same client call (supabase.functions.invoke('hello')).

Same client, same channel API, same event payloads

Same client, same channel API, same event payloads. The realtime server inside Tinbase is a Go implementation of the Supabase realtime spec and consumes the same logical replication stream from Postgres. When Docker Supabase is still the right call Being honest about the trade-offs: You use the local Supabase dashboard heavily. Tinbase doesn't ship one yet. tinbase studio is planned, not shipped.

You depend on Supabase Storage's image transformation pipeline

You depend on Supabase Storage's image transformation pipeline. Tinbase storage is plain file I/O, no on-the-fly transforms. Your team is fine with the Docker setup and RAM isn't a constraint. Nothing to fix.

News

Running Real Postgres Locally Without Docker (with Tinbase)

Docker Supabase on an 8 GB laptop: 12 containers, ~1.6 GB RAM idle, 45 s cold boot Tinbase: one ~58 MB binary, real Postgres 17, ~100 MB RAM idle, ~2.5 s cold boot supabase-js works with zero code…

@spots #dev
Source: Dev.to
See more like this