Single-binary PocketBase alternative · Open source (MIT)A PocketBase alternative with real Postgres
tinbase lands in PocketBase’s weight class — one downloadable binary, no runtime prerequisite — while running real Postgres behind Supabase’s exact wire APIs. You get RLS, jsonb, foreign keys, and triggers, and you use the supabase-js SDK.
npx tinbase startThe honest version
Is tinbase a PocketBase alternative?
PocketBase is an excellent open-source backend in a single Go binary: SQLite for storage, a built-in admin dashboard, realtime subscriptions, auth, and file storage, extensible in Go or with JavaScript hooks. It is lightweight and production-ready.
PocketBase and tinbase share a philosophy: one small binary, no Docker, batteries included. They differ underneath. PocketBase is SQLite with its own SDK and API rules. tinbase is real Postgres (RLS, jsonb, foreign keys, triggers) behind Supabase’s wire protocols, so you use the standard supabase-js client and your migrations stay portable to hosted Supabase.
Be honest about the trade: PocketBase is lighter (about 24 MB under load versus tinbase’s ~66 MB binary) and it is production-ready today, whereas tinbase is alpha. Choose tinbase when you want Postgres semantics and the Supabase ecosystem in that same single-binary form factor, or when you need the backend to run in the browser.
Why switch
Why teams pick tinbase over PocketBase
PocketBase’s form factor, real Postgres
One downloadable binary with no Node, npm, or Docker, but backed by Postgres 17 rather than SQLite — RLS, jsonb, foreign keys, and triggers included.
Use the Supabase SDK and ecosystem
Talk to it with the official supabase-js client and the PostgREST query grammar, and keep your supabase/migrations portable to hosted Supabase.
Postgres power, per-request RLS
Full SQL, PL/pgSQL, triggers, and Row Level Security enforced on every REST, Storage, and realtime request with your JWT claims applied.
Runs in the browser too
Beyond the server binary, tinbase can run in-process in a browser tab via PGlite or the pure-JS pg-mem engine, for previews and offline apps.
Side by side
tinbase vs PocketBase
The short version. For the full breakdown and when PocketBase is the better call, see the complete tinbase vs PocketBase comparison.
| tinbase | PocketBase | |
|---|---|---|
| License | MIT, open source | MIT, open source |
| Runtime | Node, or standalone binary | Go, standalone binary |
| Database | Real Postgres 17 | SQLite |
| Postgres features (RLS, jsonb, FKs, triggers) | Yes | SQLite equivalents only |
| Client SDK | supabase-js | PocketBase SDK (JS / Dart) |
| Single binary | Yes, ~58 MB | Yes, ~30 MB |
| Memory under load | ~66 MB (binary) | ~24 MB |
| Runs in the browser / embedded | Yes (PGlite / pg-mem) | No, server only |
| Realtime | postgres_changes, broadcast, presence + RLS | Realtime subscriptions |
| Auth | Email, OAuth, magic link, MFA/TOTP | Email, OAuth, OTP |
| Storage | S3-style, RLS, signed URLs, TUS | File storage, S3 backend |
| Admin dashboard | Studio (Supabase-style) at /_/ | Built-in admin UI |
| Access control | Postgres RLS (SQL policies) | Collection API rules |
| Extensibility | SQL, Edge Functions, webhooks, cron | Go extensions / JS hooks |
| Ecosystem portability | supabase-js + migrations portable to Supabase | PocketBase-specific |
| Production maturity | Alpha | Production-ready, mature |
Pick the right tool
Choose tinbase if
- You want real Postgres semantics (RLS, jsonb, FKs, triggers), not SQLite
- You want the Supabase SDK and migrations that stay portable to hosted Supabase
- You need the backend to run in a browser tab or embedded, not just as a server
- Per-request Row Level Security in SQL matters to you
Stick with PocketBase if
- You want the absolute lightest footprint (~24 MB under load)
- You are shipping to production now and want a mature, proven backend
- SQLite fits your workload and you like extending the backend in Go
- A single self-contained file with the smallest possible surface is the priority
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
Frequently asked questions
- How is tinbase different from PocketBase?
- Both are single-binary, Docker-free backends. PocketBase uses SQLite and its own SDK and API rules. tinbase runs real Postgres (RLS, jsonb, foreign keys, triggers) behind Supabase’s wire protocols, so you use supabase-js and keep migrations portable to hosted Supabase. PocketBase is lighter and production-ready; tinbase is alpha.
- Is tinbase as lightweight as PocketBase?
- Close, but PocketBase is lighter. PocketBase runs at about 24 MB of RAM under load; the tinbase single binary is about 66 MB. tinbase trades that extra footprint for a full Postgres engine and Supabase-compatible APIs.
- Does tinbase have an admin UI like PocketBase?
- Yes. tinbase ships Studio, a Supabase-Studio-style dashboard, at /_/. It includes a table editor, SQL editor, auth and RLS management, storage, and logs, and it compiles into the single binary.
- Can I use Postgres features PocketBase’s SQLite lacks?
- Yes. Because tinbase is real Postgres, you get jsonb, foreign keys, triggers, PL/pgSQL, Row Level Security, and the wider Postgres extension surface, all through the standard supabase-js client.
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.
npx tinbase start