- tinbase is an open-source (MIT) backend that speaks the Supabase API but runs as a single process on real Postgres 17 — no Docker, no container orchestration.
- It's
supabase-jscompatible, so a lot of existing Supabase client code points at it unchanged. - Because it drops the container requirement, it runs where the full stack can't: lightweight CI, low-spec machines, and in the browser.
- Built by Sanket Sahu. MIT-licensed and open to contributions.
If you've run Supabase locally, you know the ritual: install Docker, start the stack, wait for Postgres, GoTrue, PostgREST, Realtime, and Storage to spin up, and watch your laptop fans kick in.
For a lot of workflows — quick local iteration, CI, teaching, browser sandboxes — that's more machinery than the task needs.
tinbase is a different bet: the Supabase API surface, on real Postgres, as one process.
What it actually is
tinbase is an open-source backend that provides Supabase-compatible APIs while running as a single process on PostgreSQL 17, with no Docker requirement.
The design goals in one line each:
- Real Postgres, not a shim. It runs on Postgres 17, so SQL behavior matches production. No SQLite dialect gaps to trip over when you deploy.
-
supabase-jscompatible. Client code written against Supabase can, in many cases, point at a tinbase instance without changes. - Single process, no Docker. One thing to start. No container stack to orchestrate or resource-tune.
- Runs in the browser. Because it sheds the container requirement, tinbase can run in environments a Docker stack simply can't — including in-browser sandboxes.
- MIT-licensed. Fully open source. Inspect it, self-host it, contribute to it.
Why single-process, Docker-free matters
The architecture isn't the point — what it unlocks is.
Faster local loops. A single process starts in a fraction of the time an orchestrated multi-container stack takes. The edit-run-test cycle gets shorter.
Cheaper CI. CI runners are memory-constrained and billed by the minute. Spinning up one Postgres-backed process per job is dramatically lighter than booting the full Supabase container set.
Teaching and demos that just run. Workshops and tutorials can hand out a real backend without first walking every participant through installing and configuring Docker. That alone removes the most common "it doesn't work on my machine" failure at the start of a session.
Browser and constrained environments. In-browser IDEs and low-spec machines that can't host the full container stack can still run a real Supabase-compatible backend.
How it compares
If you want a lighter local Supabase, you've probably weighed these:
| Option | Real Postgres? | Docker-free? | Supabase-compatible? |
|---|---|---|---|
| Full Supabase CLI stack | Yes | No | Yes |
| SQLite-based shim | No | Yes | Partial |
| Hand-rolled Postgres + PostgREST | Yes | Depends | You wire it |
| tinbase | Yes | Yes | Yes |
The gap tinbase fills: the realism of Postgres-backed Supabase, without the Docker overhead, and without dropping to a non-Postgres engine that diverges from production.
Who it's for
- Developers who want a fast local Supabase without the container tax
- Teams trying to cut CI time and cost
- Educators and content authors who need a reproducible backend in a tutorial
- Anyone building in a browser sandbox or on constrained hardware
Getting started
tinbase is single-process and Docker-free, so setup is meant to be minimal: install, start the process, and point a supabase-js client at it.
The full documentation and source are at tinbase.dev.
If you've been avoiding local Supabase because of the Docker overhead, this is worth a look — especially for CI and teaching setups.
Running Supabase locally today? What's your current setup — full CLI stack, a shim, or something hand-rolled? Curious what the pain points have been.
Top comments (0)