Open-source Firebase alternative · Open source (MIT)An open-source Firebase alternative on real SQL
If you want relational SQL, your own data, and no vendor lock-in, tinbase is an open-source alternative to Firebase built on real Postgres. Auth, storage, and realtime included, self-hostable in one binary, and able to run in the browser.
npx tinbase startThe honest version
Is tinbase a Firebase alternative?
Firebase is Google’s proprietary, cloud-hosted backend-as-a-service: NoSQL databases (Firestore and Realtime Database), Authentication, Cloud Functions, Hosting, and a large mobile-first ecosystem including FCM push notifications. It is not open source and cannot be self-hosted.
tinbase and Firebase solve the same job, a backend without writing one, but from opposite ends. Firebase is proprietary, NoSQL, and cloud-only. tinbase is open source (MIT), relational Postgres, and self-hostable, so you own your data and your infrastructure.
Be clear-eyed about the switch: tinbase uses the supabase-js SDK and SQL, not the Firebase SDK, so moving an existing Firebase app means rewriting data access and remodelling documents as relational tables. And tinbase is alpha, while Firebase is a mature, planet-scale managed service. The reasons to make that trade are SQL, ownership, offline and embedded use, and escaping lock-in, not feature-for-feature parity today.
Why switch
Why teams pick tinbase over Firebase
Real SQL and real relations
Postgres with joins, foreign keys, constraints, transactions, and jsonb, instead of denormalised NoSQL documents. Query with full SQL, not a limited document API.
Own your data, no lock-in
Open source and MIT-licensed on standard Postgres. Self-host it anywhere, export freely, and never depend on a single vendor’s proprietary APIs or pricing.
Runs offline and in the browser
Every service is a pure fetch handler, so the entire backend can run in-process in a browser tab or on-device, persisting locally, with no cloud round-trip.
Row Level Security in plain SQL
Authorization is Postgres RLS: versionable SQL policies enforced on every request, instead of a separate security-rules DSL.
Side by side
tinbase vs Firebase
The short version. For the full breakdown and when Firebase is the better call, see the complete tinbase vs Firebase comparison.
| tinbase | Firebase | |
|---|---|---|
| License | MIT, open source | Proprietary (Google) |
| Database | Real Postgres 17 | Firestore / Realtime DB (NoSQL) |
| Data model | Relational: joins, FKs, constraints | Document / key-value NoSQL |
| Query language | Full SQL + PostgREST | SDK query API, limited joins |
| Client SDK | supabase-js | Firebase SDK |
| Self-hosting | Yes, single binary | No, Google-hosted only |
| Vendor lock-in | None — standard Postgres, export freely | High — proprietary APIs & hosting |
| Runs in the browser / embedded | Yes, in-process | Offline cache only, no self-host |
| Managed cloud hosting | Not yet (on the roadmap) | Yes, mature global infra |
| Production maturity | Alpha | Battle-tested at scale |
| Realtime | postgres_changes, broadcast, presence | Firestore / RTDB listeners |
| Auth | Email, OAuth, magic link, MFA/TOTP | Many providers, phone, anonymous |
| Storage | S3-style with RLS, signed URLs | Cloud Storage |
| Access control | Postgres RLS (SQL policies) | Security Rules (custom DSL) |
| Push notifications | Not built-in | FCM, mature |
| Pricing | Free, open source | Pay-as-you-go, can scale costly |
Pick the right tool
Choose tinbase if
- You want relational SQL, joins, and transactions rather than NoSQL documents
- You need to own your data and self-host, with no vendor lock-in
- You want the backend to run offline, in the browser, or embedded on-device
- You prefer authorization as versioned SQL policies (RLS)
Stick with Firebase if
- You want a fully managed, planet-scale service with no infrastructure to run
- You depend on Google’s ecosystem: FCM push, Analytics, Crashlytics, mobile SDKs
- You are shipping to production now and need a battle-tested platform
- A document / NoSQL model fits your data better than relational tables
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
- Is tinbase a good Firebase alternative?
- It is a strong fit if what pulls you away from Firebase is the lack of SQL, self-hosting, or data ownership. tinbase gives you relational Postgres, open-source MIT licensing, and self-hosting in a single binary. It is not a fit if you need Firebase’s managed global scale or its mobile ecosystem today, since tinbase is alpha.
- Can I migrate a Firebase app to tinbase without changes?
- No. Firebase and tinbase use different SDKs and different data models. Moving over means switching to the supabase-js client and remodelling Firestore documents as relational Postgres tables. The upside is standard SQL and no lock-in afterwards.
- Does tinbase support realtime like Firebase?
- Yes. tinbase provides realtime through postgres_changes, broadcast, and presence, with Row Level Security applied so subscribers only receive events for rows they can see. The API is the Supabase Realtime protocol rather than Firestore listeners.
- Is tinbase free?
- Yes, tinbase is free and open source under the MIT license. You run it yourself, so there are no usage-based bills the way Firebase can accrue at scale.
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