Why AnvilBase

AnvilBase exists because self-hosting a full backend in 2026 is still painful. The popular options each fail in a specific way; AnvilBase is the synthesis.

The gap it fills

Self-hosted Supabase is excellent software, but:

• It has no unified dashboard across projects — each deployment’s Studio is hardwired to one database. Running 10 apps means running (and upgrading) 10 stacks.
• It is resource-heavy — one stack idles at ~1.5–2.5 GB RAM, much of it PostgREST instances.
• Its upgrade path is manual across 10+ pinned services.
• It has no official multi-tenant mode and a thin security story for regulated industries (no RLS UI to speak of, no first-class secrets vault, limited audit).

Appwrite has the multi-project console Supabase lacks, but it’s built on MariaDB — so no pgvector, no PostgREST ecosystem, no Postgres extensions — and its edge functions are less mature.

Neon and Upstash are brilliant but hosted-only building blocks (Neon = serverless Postgres with branching; Upstash = serverless Redis + queues). You can’t run them on your own metal.

AnvilBase combines the best of each: Postgres-first like Supabase, multi-project like Appwrite, with branching/PITR/queues/cache inspired by Neon and Upstash — all self-hosted.

Feature comparison

Capability	Supabase (self-host)	Appwrite	Neon	Upstash	AnvilBase
Self-hostable	⚠️ painful	✅	❌	❌	✅
Multi-project console	❌	✅	⚠️	⚠️	✅
Postgres core	✅	❌ (MariaDB)	✅	❌	✅
Auto REST API	✅ PostgREST	⚠️	❌	❌	✅ built-in engine
Vector search	✅ pgvector	❌	✅ pgvector	❌	✅ pgvector
Realtime	✅	⚠️	❌	❌	✅ Phoenix
Auth	✅	✅	❌	❌	✅ Better Auth
Object storage	✅	✅	❌	❌	✅ S3-compatible
Edge functions	✅ Deno	⚠️	❌	❌	✅ Deno
Queues	❌	❌	❌	✅	✅ PGMQ
Cache	❌	❌	❌	✅	✅ Valkey
Secrets vault	✅	❌	❌	❌	✅ pgcrypto
RLS policy UI	⚠️ basic	❌	❌	—	✅ visual + test sandbox
Audit logs	⚠️	⚠️	⚠️	⚠️	✅ immutable, exportable
EU identity (eIDAS)	❌	❌	❌	❌	✅ optional module

AnvilBase is the only row hitting every column.

RAM footprint: the multi-project math

The single biggest engineering decision is replacing PostgREST with a built-in REST→SQL engine. PostgREST binds to one database at startup, so multi-project support means N PostgREST processes:

Projects	Supabase (PostgREST containers)	AnvilBase (built-in engine)
1	~500 MB	~2–5 MB
10	~5–10 GB	~20–50 MB
100	~50–100 GB	~200–500 MB
1,000	not feasible	~2–5 GB

Per-project pools are created lazily on first request and evicted after a few minutes idle. This is what makes “many projects on one box” practical.

Where AnvilBase deliberately differs from Neon

Neon’s instant branching and instant PITR come from a custom storage engine (Pageserver) — years of specialized R&D. AnvilBase uses standard Postgres (WAL archiving via wal-g, pg_basebackup for branches) instead. The honest trade-off:

• Neon advantage: branching/PITR is near-instant (copy-on-write at the storage layer).
• AnvilBase advantage: you get full Postgres superuser, any extension (including custom-compiled), complete data residency control (air-gapped, EU-only, on-prem), no plan-tier feature gating, and no vendor lock-in — it’s plain Postgres, migrate anywhere with pg_dump. Branching takes ~30–60s for a typical dev DB rather than milliseconds.

We document this honestly rather than pretending the approaches are identical.

When not to choose AnvilBase

• You want a fully managed backend and never want to touch infrastructure → use hosted Supabase/Neon/Upstash.
• You need millisecond branch creation at massive scale as a core workflow → Neon’s storage engine is purpose-built for that.
• You’re a single tiny app and will never run more than one → hosted Supabase is less to think about.

For everyone else — especially multi-app builders and sovereignty-constrained teams — AnvilBase is built for you.

Next: Architecture.