A new open-source project called tinbase replicates the local development experience of Supabase without requiring Docker, condensing what is normally a twelve-container stack into a single process.
The Problem It's Solving
A standard Supabase local development setup pulls Postgres, PostgREST, GoTrue, Storage, Realtime, and Studio into separate Docker containers, consuming roughly 2.3 GB of disk space and around 1.6 GB of RAM under load, a heavy footprint for developers who just want to build a simple app locally.
How tinbase Compresses the Stack
tinbase implements the PostgREST query grammar, GoTrue's authentication flows, the Storage API, and the Realtime Phoenix protocol directly, verified against Supabase's own test suite, rather than wrapping or forking the existing services. Because it targets the same APIs, the standard supabase-js client works unmodified, row-level security policies enforce correctly against a user's JWT claims, and Realtime performs per-subscriber filtering so users only receive change events for rows they're authorized to see.
Authentication support spans email and password login, anonymous sessions, one-time passcodes, magic links, password recovery, and OAuth through Google, GitHub, or generic providers using PKCE. Edge Functions run in-process, and a Supabase Studio-style dashboard ships alongside the runtime.
One Process, Three Ways to Run It
Every tinbase service sits on top of a swappable database engine layer: a native embedded Postgres 17 instance, PGlite (Postgres compiled to WebAssembly), or a pure JavaScript in-memory engine called pg-mem. In Node, the whole stack runs as an HTTP and WebSocket server behind a single 58 MB executable requiring no Node, npm, or Docker installation. In the browser, the same handler can run inside a tab as a custom fetch implementation for supabase-js, meaning the entire backend, Postgres included, executes client-side with no server involved at all.
From Internal Tool to Open Source Release
tinbase grew out of the creators' own need to run a full dev stack, database, auth, storage, and realtime, without VMs or cloud infrastructure behind it. The project reads and writes the same supabase/migrations files as the official Supabase CLI, so teams can outgrow the local tool and push the same migrations to hosted Supabase without rework. It reports 168 out of 168 integration tests passing across both engines and is released under the MIT license, positioned explicitly for local development, prototyping, and embedded or browser use rather than production deployment.