Tinbase packs Postgres 17 and Supabase-compatible layers into a 58 MB binary with 2.5 s boot

A post on dev.to's home feed introduces Tinbase, an MIT-licensed single binary that runs genuine PostgreSQL 17 alongside Supabase-compatible auth, realtime and edge-function layers. The author, who discloses working on the project, reports that the binary weighs about 58 MB, idles at roughly 100 MB of RAM and cold-boots in around 2.5 seconds. For comparison, a Docker-based Supabase stack on the same 8 GB MacBook Air spans 12 containers, sits near 1.6 GB of RAM when idle and takes about 45 seconds to start cold. The project is not affiliated with Supabase and targets the supabase-js client contract rather than replacing the hosted platform; the current release is 0.9.4, with source on GitHub under tinbase-dev/tinbase.

Real Postgres in one process

Installation on macOS and Linux is a curl script, while Windows users fetch an executable from the releases page. After tinbase start with a data directory, an HTTP endpoint listens on port 8080 and Postgres answers on the standard port 5432. Warm restarts reportedly take about 800 milliseconds.

The post is deliberate about what is running: PostgreSQL 17.1 itself — not PGlite, the WASM build of Postgres with the client-server machinery stripped out, and not SQLite behind a Postgres wire adapter. A one-line select version(); through psql confirms it.

Several extensions ship enabled by default, including pgvector for embeddings, pg_trgm for fuzzy text matching, pg_stat_statements for query profiling, unaccent, pgcrypto and uuid-ossp. Anything else loads through the ordinary create extension statement.

Compatibility with the Supabase client

The main pitch to existing Supabase users is that application code stays untouched. Point SUPABASE_URL at localhost:8080 with the anon key printed at startup, and existing supabase-js calls — sign-in via signInWithPassword, table queries, functions.invoke — behave as before.

Row-level security gets particular attention: because the database is real Postgres, policies that rely on auth.uid(), supplied by Tinbase's auth layer, should pass locally and behave the same on hosted Supabase.

Edge functions execute inside an embedded V8 engine rather than a Deno subprocess, with a reported cold start near 15 milliseconds, and expose the same HTTP surface as Supabase Edge Functions. The realtime component is a Go implementation of the Supabase realtime specification that reads Postgres's logical replication stream, so channel subscriptions and postgres_changes payloads look identical to clients.

Migration path and current gaps

Moving an existing project is a dump-and-import flow: supabase db dump to a file, then tinbase import. The importer warns about Supabase-specific extensions or hooks it does not yet support, and a compatibility matrix is documented alongside the import command — worth checking before committing an afternoon.

The author is upfront about where the Docker setup still wins. There is no local dashboard yet; a tinbase studio is planned but not shipped. Storage amounts to ordinary filesystem reads and writes, without Supabase Storage's dynamic image transformations. And teams whose machines handle the container stack's footprint comfortably have nothing to fix.

Why it matters

Local Supabase development has quietly become heavy: the stack that runs on every laptop and in every CI job pays a fixed tax in containers, memory and boot time. Collapsing that to a single binary that idles at roughly 100 MB and boots in seconds changes what is practical on constrained laptops, in CI runners and in workshop settings.

The caveats deserve equal weight. Every figure above is self-reported by someone who works on the project, measured on one laptop, and the software is at version 0.9.x. Independent benchmarks and reports from production-shaped projects have not surfaced yet. Still, the deciding factor is the compatibility claim: if RLS, auth and realtime genuinely match the hosted contract, the usual drift between local and production environments shrinks, and Docker becomes a choice rather than a prerequisite.