Comparison
tinbase vs Appwrite
Both are open-source backends-as-a-service. The split is deployment and data model: tinbase is one Docker-free process on Postgres with the Supabase SDK, while Appwrite is a mature multi-container platform on MariaDB with SDKs for many languages.
At a glance
tinbase
Docker-free single-process Postgres, wire-compatible with Supabase.
Appwrite
A mature multi-SDK platform, self-hosted via Docker.
Feature by feature
tinbase vs Appwrite, compared
Colour is a hint, not a verdict: green marks a tinbase strength, amber an area where it is still catching up. Footprint figures come from the reproducible benchmarks.
| 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 |
Which should you choose?
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
Choose 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
Keep exploring
Appwrite alternativeWhy tinbase works as a Appwrite alternative, and the migration path.tinbase vs SupabaseThe full managed production platform, cloud-hosted and battle-tested.tinbase vs FirebaseA mature, managed, mobile-first NoSQL cloud at global scale.tinbase vs PocketBaseThe lightest single-binary backend, on SQLite, production-ready.
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