Is tinbase a drop-in replacement for Supabase?

For local development, largely yes: tinbase is wire-compatible, so supabase-js and your supabase/migrations work unchanged. It is not a replacement for the hosted Supabase cloud in production — tinbase is alpha and aimed at local dev, prototypes, CI, and embedded or in-browser use. Hosted Supabase stays the production destination.

Do I have to rewrite my code to use tinbase?

No. tinbase implements the same PostgREST, GoTrue, Storage, and Realtime protocols, so you point the official supabase-js client at it and your existing queries, auth flows, and realtime subscriptions run as-is.

Can I move from tinbase to hosted Supabase later?

Yes, that is the intended path. tinbase reads and writes the same supabase/migrations/*.sql and seed.sql files with the same tracking table, so you push the same files to hosted Supabase when you are ready for production.

How much lighter is tinbase than local Supabase?

The Supabase CLI local stack runs about 12 containers at roughly 1.4-1.6 GB of RAM. tinbase serves the same APIs from one process at about 59 MB (native engine) to 66 MB (single binary) under load, and boots in about two seconds instead of a minute.

Docker-free Supabase alternative · Open source (MIT)

A Supabase alternative that fits in a tin

Run local Supabase development without Docker. tinbase speaks the same wire protocols, so the official supabase-js SDK and your supabase/migrations work unchanged — in one process, at roughly 16-24x less memory than the Supabase CLI stack.

Get started tinbase vs Supabase →

npx tinbase start

The honest version

Is tinbase a Supabase alternative?

Supabase is the leading open-source Postgres backend-as-a-service: a managed cloud platform plus a self-hostable stack (PostgREST, GoTrue, Storage, Realtime, Studio). Its local development story is the Supabase CLI, which boots a 12-container Docker stack.

tinbase is not a fork or a competitor to hosted Supabase. It is wire-compatible with it. The same supabase-js SDK, the same PostgREST query grammar, the same supabase/migrations and seed conventions all work against tinbase unchanged, so the honest way to describe it is a drop-in alternative to the Supabase CLI local stack — not to the Supabase cloud.

That means the migration path runs both ways. Develop locally on tinbase with no Docker, then push the exact same migration files to hosted Supabase for production. tinbase is alpha and best for local dev, prototypes, CI, and embedded or in-browser use; hosted Supabase remains the production destination.

Why switch

Why teams pick tinbase over Supabase

No Docker, no 12-container stack

The Supabase CLI boots a dozen containers. tinbase is one process, or one ~58 MB binary with no Node, npm, or Docker on the machine.

The same SDK and migrations

supabase-js works unchanged, and your supabase/migrations/*.sql and seed.sql apply with the same conventions and tracking table — so everything stays portable to hosted Supabase.

Boots in ~2s, ~16-24x less RAM

Real Postgres 17 at ~59 MB (native) or ~66 MB (binary) under load, versus ~1.6 GB for the local Supabase stack. Starts serving requests in about two seconds instead of a minute.

Runs in the browser

Every service is a pure fetch handler. Hand it to supabase-js as a custom fetch and the whole backend, database included, runs in-process for previews and offline demos.

Side by side

tinbase vs Supabase

The short version. For the full breakdown and when Supabase is the better call, see the complete tinbase vs Supabase comparison.

	tinbase	Supabase
License	MIT, open source	Apache 2.0, open source
Database	Real Postgres 17 (native or WASM)	Managed Postgres
Client SDK	supabase-js, unchanged	supabase-js
Local dev without Docker	Yes, one process	No, 12-container Docker stack
Runs in the browser / embedded	Yes (PGlite / pg-mem in-process)	No
Memory (local dev)	~59 MB native, ~66 MB binary	~1.4-1.6 GB local stack
Boot time (local)	~2 s	~1 min (containers)
Self-hosting	Single binary, no runtime deps	Docker Compose / Kubernetes
Managed cloud hosting	Not yet (on the roadmap)	Yes, mature managed platform
Production maturity	Alpha — local / prototype / embedded	Production-ready, widely used
Realtime	postgres_changes, broadcast, presence + RLS	Same
Auth	Email, OAuth, magic link, MFA/TOTP	Full GoTrue incl. phone, SSO/SAML
Storage	S3-style, RLS, signed URLs, TUS	Same, plus image transforms
Row Level Security	Postgres RLS, enforced per-request	Postgres RLS
Migrations	supabase/migrations, portable both ways	Same conventions
pgvector, SSO/SAML, phone auth, image transforms	Some planned	Available

Pick the right tool

Choose tinbase if

You want local Supabase development without running Docker
You need the backend to run in-process, in a browser tab, or inside a single binary
You care about a tiny memory footprint and ~2s boot for CI and prototypes
You want to keep supabase-js and your migrations portable to hosted Supabase later

Stick with Supabase if

You need a managed, production-grade cloud backend today
You rely on features tinbase has not reached yet, such as SSO/SAML, phone auth, pgvector, or image transforms
You want managed backups, scaling, dashboards, and team collaboration

Getting started

Keep the SDK you already know

tinbase implements the PostgREST query grammar, GoTrue auth, the Storage API, and the Realtime protocol, verified by running the official supabase-js against it. Point the client at tinbase and your code runs.

Read the docs →

import { createClient } from '@supabase/supabase-js'

// tinbase speaks the same wire protocol, so the official SDK is unchanged
const supabase = createClient('http://127.0.0.1:54321', ANON_KEY)

await supabase.auth.signUp({ email, password })
await supabase.from('todos').insert({ title: 'hello' })
const { data } = await supabase.from('todos').select('*').eq('done', false)

Compare with other backends

tinbase vs SupabaseThe full, feature-by-feature comparison with Supabase.Firebase alternativeOpen-source Firebase alternative PocketBase alternativeSingle-binary PocketBase alternative Appwrite alternativeDocker-free Appwrite alternative

Frequently asked questions

Is tinbase a drop-in replacement for Supabase?: For local development, largely yes: tinbase is wire-compatible, so supabase-js and your supabase/migrations work unchanged. It is not a replacement for the hosted Supabase cloud in production — tinbase is alpha and aimed at local dev, prototypes, CI, and embedded or in-browser use. Hosted Supabase stays the production destination.
Do I have to rewrite my code to use tinbase?: No. tinbase implements the same PostgREST, GoTrue, Storage, and Realtime protocols, so you point the official supabase-js client at it and your existing queries, auth flows, and realtime subscriptions run as-is.
Can I move from tinbase to hosted Supabase later?: Yes, that is the intended path. tinbase reads and writes the same supabase/migrations/*.sql and seed.sql files with the same tracking table, so you push the same files to hosted Supabase when you are ready for production.
How much lighter is tinbase than local Supabase?: The Supabase CLI local stack runs about 12 containers at roughly 1.4-1.6 GB of RAM. tinbase serves the same APIs from one process at about 59 MB (native engine) to 66 MB (single binary) under load, and boots in about two seconds instead of a minute.

Try it in one command

No Docker, no sign-up. Point the supabase-js SDK you already know at a real Postgres backend running in a single process.

Get started Star on GitHub

npx tinbase start