If you want a Supabase-style backend on your own servers, there are four realistic choices: self-host Supabase itself, run Appwrite, run PocketBase, or run the self-hosted edition of WoWSQL. They differ most in three ways: whether the database is Postgres, how many moving parts you operate, and how the licence treats you. This post compares them as of 19 October 2026, with the limits stated plainly.
Key facts
- Supabase can be self-hosted with Docker (repo licence Apache-2.0). It's the closest match to Supabase Cloud, and also the most services to run.
- Appwrite (BSD-3-Clause) self-hosts with Docker or a Helm chart. It isn't built around a single Postgres database you query with SQL.
- PocketBase (MIT) is a single Go binary with embedded SQLite. It's still pre-1.0, so backward compatibility isn't guaranteed.
- WoWSQL self-hosted (github.com/WoWSQL/WoWSQL, Apache-2.0) runs PostgreSQL 18, PostgREST, Kong, Redis, Auth, Storage, Realtime and a Studio dashboard with
docker compose up. It needs 4 GB RAM minimum.- WoWSQL's limits: one admin user and one project, with no managed backups, auto-scaling or team collaboration. Auth, Storage and Realtime ship as prebuilt Docker images.
What people mean by "self-hosted Supabase alternative"
Usually one of three things:
- "I want Supabase, but on my own hardware." That's data control, a fixed server bill, or an air-gapped network.
- "I want something lighter than Supabase's Docker stack" for a side project or an internal tool.
- "I want to develop locally against the same APIs I'll use in production."
Each option below suits a different one of these.
Comparison table
Licences come from each project's GitHub repository. Stack details come from each project's own docs or compose files, checked 19 October 2026.
| Supabase (self-hosted) | Appwrite | PocketBase | WoWSQL self-hosted | |
|---|---|---|---|---|
| Licence | Apache-2.0 | BSD-3-Clause | MIT | Apache-2.0 |
| Database | PostgreSQL | Several engines in the default compose file (MariaDB, MongoDB, a Postgres image) behind Appwrite's own Databases API | Embedded SQLite | PostgreSQL 18 |
| REST over your tables | PostgREST | Appwrite APIs | PocketBase REST-ish API | PostgREST v12.2.0 |
| Deploy | Docker Compose | Docker, Helm chart, marketplace images | One binary | Docker Compose |
| Multi-project | Yes | Yes | One app per binary | No: single project |
| Users of the dashboard | Studio | Console with teams | Admin UI | Single admin user |
| Maturity signal | Largest community (≈112k GitHub stars) | ≈58k stars, release 2.5.0 on 13 Oct 2026 | ≈61k stars, v0.40.5, pre-1.0 | 46 stars, first release 12 Jun 2026 |
Star counts are a rough signal of community size. They tell you nothing about quality.
Supabase, self-hosted
Supabase publishes a Docker setup, and its pricing FAQ confirms you can self-host for free. Studio is included. The docker/ folder has compose variants for different Postgres versions, a connection pooler, and S3-backed storage.
Good fit: you already use Supabase Cloud, or you want the widest set of examples and integrations.
Watch out for: the number of services you'll be patching and monitoring, and features that are cloud-only or work differently when self-hosted. Read the self-hosting docs before you commit.
Appwrite
Appwrite says it was "designed from the ground up with self-hosting in mind". It runs anywhere Docker runs, has an official Helm chart, and offers one-click images on DigitalOcean, Akamai and AWS Marketplace. It covers auth, databases, storage, functions, messaging and realtime.
Good fit: teams that like Appwrite's API model and want functions and messaging in the same box.
Watch out for: it isn't a "plain Postgres plus PostgREST" design. If you want to write SQL and Row Level Security policies against one Postgres database, Appwrite works differently. Appwrite's own docs also warn that self-hosting "often costs more when factoring in time and expertise".
PocketBase
PocketBase is one Go executable with SQLite, realtime subscriptions, auth, file storage and an admin UI. Download it, run it, done.
Good fit: prototypes, internal tools and small apps where one process on one server is fine.
Watch out for: the README warns that full backward compatibility isn't guaranteed before v1.0.0. And SQLite isn't Postgres: no Postgres extensions, and a different scaling model. Moving to Postgres later means a migration.
WoWSQL self-hosted
WoWSQL's self-hosted edition is a Postgres-first stack behind one Kong gateway:
| Path | Service |
|---|---|
/rest/v1/* |
PostgREST |
/auth/v1/* |
Auth (wowsql/auth) |
/storage/* |
Storage (wowsql/storage) |
/realtime/* |
Realtime (wowsql/realtime) |
/api/v1/* |
Dashboard backend (FastAPI) |
The dashboard is on port 3000 and the API gateway on port 8080. The Postgres image enables uuid-ossp, pgcrypto and vector at init. RLS is opt-in per table, and the init SQL ships the helpers auth.uid(), auth.role() and auth.jwt().
Quickstart, from the README:
git clone https://github.com/WoWSQL/WoWSQL.git
cd WoWSQL/docker
cp .env.example .env # set POSTGRES_PASSWORD and a JWT_SECRET of 32+ characters
docker compose pull
docker compose up -d
Open http://localhost:3000 and create the admin account. Then point the TypeScript SDK at the gateway:
import WowSQLClient from '@wowsql/sdk'
const client = new WowSQLClient({
projectUrl: 'http://localhost:8080',
apiKey: 'YOUR_ANON_KEY',
secure: false,
})
const { data } = await client.table('todos').select('*').get()
If you've seen older snippets that call createClient or .from(), note that @wowsql/sdk 3.10.0 exports neither. Use new WowSQLClient({...}).table(...) as shown.
Good fit: a local development environment that matches WoWSQL Cloud's paths (/rest/v1, /auth/v1, /storage/v1, /realtime/v1), or a single-project app on your own server.
Honest limits:
- One admin user and one project. No team collaboration.
- No managed backups and no auto-scaling. Back up the Docker volumes yourself.
- Custom domains and TLS are do-it-yourself.
- The repo contains the compose file, Kong config, Studio and the dashboard backend. Auth, Storage and Realtime are pulled as prebuilt images from Docker Hub, and their source isn't in this repo.
- The project is young: first release 12 June 2026, latest 1.2.1 on 7 October 2026.
- The SDKs are under the Elastic License 2.0, not Apache-2.0.
Before you self-host anything
Whichever you pick, put these in place before real users arrive:
- Backups you have restored at least once. Run
pg_dumpon a schedule, and keep volume snapshots off the box. - Upgrades. Pin image versions, then read the changelog before you run
docker compose pull. - Secrets. Rotate the default JWT secret and passwords, and keep
.envout of git. - TLS and a reverse proxy in front of the gateway.
- Monitoring for disk, memory and Postgres connections.
If that list sounds like more than you want to run, a managed plan is cheaper than your time. WoWSQL Cloud runs in Mumbai and US East 1 from $25/month, and the same APIs work on both editions.
Related reading
- WoWSQL Self-Hosted: your backend, your servers, your rules
- Best Supabase alternatives in 2026
- Indian Supabase alternative
- Self-hosting docs · Docker setup
Frequently asked questions
Can I self-host Supabase for free?
Yes. Supabase's pricing FAQ says you can self-host with the Docker setup or the Supabase CLI. You pay for your own servers and the time you spend running them.
Is WoWSQL's self-hosted edition open source?
The repository github.com/WoWSQL/WoWSQL is Apache-2.0. The Auth, Storage and Realtime services are pulled as prebuilt images whose source isn't in that repo, and the client SDKs are Elastic-2.0.
How much RAM does WoWSQL self-hosted need?
The README states a 4 GB RAM minimum and Docker Compose v2.
Is PocketBase a good Supabase alternative?
For small apps, yes. It's a single binary and very simple to run. It uses SQLite rather than Postgres, and it's still before v1.0, so check the changelog before you upgrade.
Can I move from WoWSQL self-hosted to WoWSQL Cloud?
Both are standard Postgres with the same API paths, so a pg_dump and restore plus a change of projectUrl and API key is the usual route. Test your RLS policies after the move.