# tinbase

> Supabase-compatible backend in a single binary — real Postgres with RLS, no Docker, works with supabase-js unchanged, and even runs in the browser.

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`.

## Features
- Supabase-compatible REST, Auth, Storage, Realtime, and Edge Functions APIs
- Official supabase-js SDK works unchanged
- Three database engines: native Postgres 17, PGlite WASM, and pure-JS pg-mem
- Single 57 MB executable, no Docker or Node required on target machine
- Runs entirely in-process inside a browser tab
- Real Row Level Security (RLS) enforced on REST, Storage, and Realtime
- Built-in Studio dashboard (table editor, SQL, auth, storage, RLS policies)
- Supabase CLI migration conventions (supabase/migrations/*.sql, seed.sql)
- Database webhooks (CDC → HTTP)
- Cron scheduling (pg_cron API)
- Message queues (pgmq subset)
- HTTP from SQL (pg_net)
- OAuth with PKCE (Google, GitHub, generic providers)
- TypeScript type generation (tinbase gen types typescript)
- Realtime postgres_changes with per-subscriber RLS filtering
- Broadcast and presence via Phoenix protocol
- Edge Functions with Deno.serve and export-default handler support
- 120 tests run against real supabase-js SDK

## Integrations
supabase-js (@supabase/supabase-js), PGlite (@electric-sql/pglite), pg-mem, Postgres 17, Bun, Node.js, Google OAuth, GitHub OAuth, Supabase CLI, IndexedDB, OPFS

## Platforms
WEB, CLI, API, DEVELOPER_SDK, LINUX, MACOS, WINDOWS

## Pricing
Open Source

## Version
v0.6.1

## Links
- Website: https://www.tinbase.dev
- Documentation: https://www.tinbase.dev/docs
- Repository: https://github.com/tinbase/tinbase
- EveryDev.ai: https://www.everydev.ai/tools/tinbase