tinbase

tinbase is an open-source, MIT-licensed Supabase-compatible backend that runs as a single process — no Docker, no 12-container stack. Built by Sanket Sahu and originating from the lifo and RapidNative projects, it implements the same wire protocols as hosted Supabase (PostgREST, GoTrue, Storage, Realtime Phoenix) so the official @supabase/supabase-js SDK works without modification.

What It Is

tinbase is a local backend-as-a-service runtime that replaces supabase start without requiring Docker. It ships REST, Auth, Storage, Realtime, Edge Functions, database webhooks, cron, and queues — all served from a single (Request) => Response fetch handler. The same handler runs as an HTTP + WebSocket server in Node or entirely in-process inside a browser tab, making it suitable for local development, prototypes, embedded apps, and browser-based full-stack use cases.

Three Engines, One API

tinbase offers three swappable database engines behind the same Supabase-compatible API surface:

• native (default on macOS/Linux): embedded Postgres 17, ~59 MB RAM at boot, ~12 MB binary download on first run, real RLS/triggers/FKs
• wasm: PGlite (Postgres compiled to WASM), zero setup, runs anywhere Node runs and in the browser; WASM heap sits around 575–650 MB
• pgmem: pure-JS in-memory subset via pg-mem, ~3.6 MB install, no WASM — lightest option for browser previews, but no RLS or cron

The native and wasm engines share identical bootstrap, migrations, RLS enforcement, and realtime CDC; the test suite passes on both.

Footprint and Performance

The homepage benchmarks (measured on Apple Silicon, macOS 15) show the single binary at ~57 MB install size and ~66 MB physical memory under load, compared to the Supabase local Docker stack at 2,291 MB install and 1,626 MB under load. The native engine boots in approximately 2 seconds and passes 120 tests run against the real @supabase/supabase-js SDK. A single compiled executable (built with Bun) requires no Node, npm, or Docker on the target machine.

What's Implemented

tinbase covers roughly 80% of the supabase-js SDK surface — and, per the project's own estimate, approximately 90% of what a typical CRUD + auth + storage + realtime app calls:

• REST (PostgREST): full filter grammar, embedded resources, RPC, upsert, count, RLS
• Auth (GoTrue): email/password, anonymous, OTP, magic links, OAuth (Google/GitHub + generic) with PKCE, refresh rotation, admin CRUD
• Storage: bucket CRUD, upload/download, signed URLs, list/move/copy/remove, pluggable driver
• Realtime: postgres_changes with per-subscriber RLS filtering, broadcast, presence, Phoenix v1+v2 serializers
• Edge Functions: supabase.functions.invoke(), Deno.serve-style and export-default handlers
• Queues (pgmq), Cron (pg_cron API), HTTP from SQL (pg_net), Database Webhooks
• Studio: built-in Supabase-Studio-style dashboard at /_/ — table editor, SQL editor, auth, storage, RLS policies, live logs

Known gaps include MFA/SSO/phone auth, resumable TUS uploads, image transformations, aggregate functions in select, and pgvector support.

Browser and Embedded Use

Every service being a pure fetch handler means the entire backend — database included — can run in-process inside a browser tab by passing the handler to supabase-js as a custom fetch. The createBackend() API supports this embedding pattern in both Node and browser environments, with PGlite persisting data via IndexedDB or OPFS. This architecture was the original motivation: enabling Expo apps to run fully in the browser with full-stack capability through the RapidNative project.

Update: v0.6.1

The latest release is v0.6.1, published on 2026-07-08, with the repository created on 2026-07-05. The project is explicitly labeled alpha — not production-ready and is recommended for local development, prototypes, and embedded/browser use. The roadmap targets becoming a near-complete Docker-free replacement for supabase start.