Docker-free Appwrite alternative · Open source (MIT)An Appwrite alternative with no Docker
tinbase is an open-source alternative to Appwrite that skips Docker entirely. Real Postgres and full SQL in a single process or binary, small enough to run in a browser tab, talking to the supabase-js SDK.
npx tinbase startThe honest version
Is tinbase a Appwrite alternative?
Appwrite is a popular open-source backend-as-a-service: a document-style database over MariaDB, plus auth, storage, functions, realtime, and messaging, with SDKs for many languages. You self-host it with Docker Compose (a multi-container deployment) or use Appwrite Cloud.
Appwrite and tinbase are both open-source BaaS, but the deployment shape is the sharpest difference. Appwrite self-hosting means a multi-container Docker Compose stack over MariaDB. tinbase is a single process, or one binary, running real Postgres, light enough to run in the browser.
The honest trade-offs: Appwrite is production-ready, ships SDKs for many languages, and has built-in messaging and a rich console. tinbase is alpha, uses the supabase-js SDK (so moving an Appwrite app means rewriting data access), and gives you relational Postgres and SQL with a far smaller footprint. Choose tinbase when Docker-free, lightweight, SQL-native, or embeddable matters more than breadth today.
Why switch
Why teams pick tinbase over Appwrite
No Docker, one process
Appwrite self-hosting is a multi-container Docker Compose stack. tinbase is a single process, or one ~58 MB binary, with nothing else to install.
Real Postgres and full SQL
Relational Postgres with joins, foreign keys, transactions, jsonb, and the PostgREST query grammar, instead of a document API over MariaDB.
A footprint you can put anywhere
Roughly 59-66 MB of RAM and a ~2s boot, versus a GB-scale multi-container deployment. Light enough for CI, laptops, and previews.
Runs in the browser
Because every service is a pure fetch handler, the whole backend can run in-process in a browser tab, which a Docker-based platform cannot do.
Side by side
tinbase vs Appwrite
The short version. For the full breakdown and when Appwrite is the better call, see the complete tinbase vs Appwrite comparison.
| tinbase | Appwrite | |
|---|---|---|
| License | MIT, open source | BSD-3, open source |
| Database | Real Postgres 17 | MariaDB (document-style) |
| Data model | Relational SQL | Collections / documents |
| Query language | Full SQL + PostgREST | Query SDK, no raw SQL |
| Client SDK | supabase-js (JS/TS) | SDKs for many languages |
| Runs without Docker | Yes, one process / binary | No, Docker Compose (multi-container) |
| Footprint | ~59-66 MB | Multi-container, GB-scale |
| Runs in the browser / embedded | Yes | No |
| Self-hosting | Single binary, no runtime deps | Docker self-host |
| Managed cloud hosting | Not yet (on the roadmap) | Appwrite Cloud |
| Realtime | postgres_changes, broadcast, presence + RLS | Realtime subscriptions |
| Auth | Email, OAuth, magic link, MFA/TOTP | Many providers, phone, teams |
| Storage | S3-style, RLS, signed URLs, TUS | File storage, image transforms |
| Messaging (email / SMS / push) | Via functions/webhooks, not built-in | Built-in Messaging |
| Access control | Postgres RLS (SQL policies) | Document-level permissions |
| Production maturity | Alpha | Production-ready |
Pick the right tool
Choose tinbase if
- You want to avoid Docker and run one process or a single binary
- You want relational Postgres and full SQL rather than a document API
- You need a small footprint or to run the backend in the browser
- You want supabase-js and migrations portable to hosted Supabase
Stick with Appwrite if
- You need SDKs across many languages (Flutter, Apple, Android, and more)
- You want built-in messaging (email, SMS, push) and a rich console today
- You are shipping to production now and want a mature platform
- You are comfortable running a Docker Compose deployment
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
- What is the main difference between tinbase and Appwrite?
- Deployment and data model. Appwrite self-hosts as a multi-container Docker Compose stack over MariaDB with a document-style API. tinbase runs as a single Docker-free process on real Postgres with full SQL and the supabase-js SDK. Appwrite is production-ready with more language SDKs; tinbase is alpha, lighter, and embeddable.
- Can tinbase run without Docker like Appwrite requires?
- Yes. Avoiding Docker is a core reason to pick tinbase. It runs as one process (npx tinbase start) or a single self-contained binary, with no containers to orchestrate.
- Does tinbase support many language SDKs like Appwrite?
- Not today. tinbase targets the JavaScript and TypeScript ecosystem through supabase-js. Appwrite ships official SDKs for many languages and platforms, so if you need broad native mobile SDK coverage, Appwrite is stronger there right now.
- Is tinbase lighter than Appwrite?
- Considerably. A self-hosted Appwrite is a multi-container deployment measured in gigabytes; tinbase serves comparable core APIs from one process at roughly 59-66 MB of RAM, and can even run in a browser tab.
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