- pglite: Postgres as an embeddable library (browser, Node, Bun, Deno). No network layer, no auth stack.
- Tinbase: single-binary local Supabase drop-in (Postgres + auth + realtime + edge functions). Supabase-JS works unchanged.
- Neither is a production database. Both make local dev, CI, and self-hosting cheaper.
The local-Postgres tooling landscape in 2026 has quietly become interesting. pglite (Supabase's WASM Postgres) has seen adoption take off. Tinbase (Shaper Studio's single-binary Supabase-compatible stack) launched recently. Docker Postgres is still the incumbent. And there's a low-grade Twitter debate about which one "wins".
Having used all three in production for different projects, I think "wins" is the wrong framing. Here's how I actually pick.
The landscape
Docker Postgres: real Postgres in a container. Well-understood. Reliable. Heavy (~500 MB image, ~200 MB RAM idle). Requires Docker itself.
pglite: Postgres compiled to WASM, embeddable in Node, browser, Bun, Deno. Under 3 MB gzipped. Perfect for scenarios where you want the SQL engine without a network layer.
Tinbase: single-file executable (~58 MB, ~100 MB RAM) that runs real Postgres plus auth, realtime, edge functions, and webhooks. Supabase-JS SDK works unchanged. Positioned as "local Supabase without Docker".
pglite's sweet spot
Use pglite when:
- You need Postgres semantics in a browser (interactive SQL tutorials, in-app query playgrounds, offline-first web apps with a real DB).
- You're building a Node/Bun tool that ships with an embedded DB (CLI tools, static-site generators, migration tools).
- Your use case is "DB embedded in the process". You don't want networked clients, you want the SQL engine as a library.
What pglite doesn't do: it's just Postgres, so no auth, no RLS enforcement (RLS is a Postgres feature but requires role setup pglite doesn't manage for you), no realtime, no PostgREST wrapper. If you're using the Supabase SDK's .from('table').select() calls, pglite alone doesn't run those. You need to also run PostgREST or write a shim.
Real use case for us: RapidNative's marketing site has an in-browser SQL playground where visitors can query a demo schema. pglite is the entire backend for that.
Tinbase's sweet spot
Use Tinbase when:
- Your production is hosted Supabase and you want your local dev to behave identically.
- You want a Supabase-compatible dev environment on machines that can't spare Docker's RAM footprint (design laptops, older machines, CI runners where you're spinning up per-test).
- You want to run integration tests against a real Supabase-compatible stack without paying for a hosted preview branch per PR.
- You're demoing at a workshop or conference and need Postgres + auth + realtime running on a laptop with no internet.
What Tinbase doesn't do: it's not designed as a production runtime. No multi-node replication, no built-in backup infrastructure, no HA. It's optimized for local dev, CI, and single-node self-hosting.
Real use case for us: local dev + CI for a shipping mobile app. Every PR gets a spun-up Tinbase for integration tests. Contributor onboarding is git clone && tinbase start && npm test. No Docker required.
The overlap zone
Both tools can serve as "local dev Postgres for a small side project". If your app is Supabase-SDK-based, Tinbase is the shorter path. If your app talks directly to Postgres (via pg / postgres.js / node-postgres), pglite is the smaller footprint.
They're also composable. pglite for browser-side experiments in an app whose backend runs Tinbase is a legitimate architecture.
What neither replaces
Hosted Supabase in production. Both tools are local-dev, self-host, or embedded oriented. If you need multi-region replication, managed backups, or a support SLA, you're still paying Supabase (or another hosted provider). Tinbase and pglite are "local matches production behavior" tools; they're not "production" tools.
Don't run either as your prod DB for a real product. Do use both to make local dev, CI, and self-host use cases much cheaper.
Deciding: a quick rubric
- "I want Postgres inside my Node/browser/Bun process" → pglite.
- "I want my local dev to behave exactly like hosted Supabase" → Tinbase.
- "I want the smallest possible dep for a demo" → pglite.
- "I want auth + realtime + edge functions locally" → Tinbase.
- "I want CI to run integration tests against a real Supabase-compatible stack" → Tinbase.
- "I want a browser-based SQL playground" → pglite.
Both tools are good. The right one depends on the shape of the problem, which is usually a better answer than "the one on the frontpage of HN this week".
Curious what your local Postgres setup looks like in 2026. Drop a comment with what you're running and why.
Disclosure: I work on Tinbase. That's why the article exists. It's also why I'm confident the honest framing "here's when NOT to use us" is a stronger sales pitch than a comparison that pretends there's a single winner. Postgres tooling has always been better as an ecosystem than a competition.
Top comments (0)