Competitor Dossier — Backend Frameworks & BaaS Platforms

Why this exists. OpenAliceLabs runs a self-hosted Rust microservice stack (axum, sqlx, per-service Postgres, EU/Hetzner). This dossier benchmarks the backend frameworks and BaaS platforms our team keeps re-researching, so we never have to again. The lens throughout is "what is this, honestly, in 2026 — and what (if anything) does it teach a Postgres-native Rust shop?" Our known gaps are the through-line: durable job queue · OTel tracing (we already have W3C trace-context propagation wired — we need a collector) · feature flags · hybrid search + reranker · typed codegen · S3/CDN · staging + blue-green.

Methodology + honesty note. Each platform was researched with a tight web budget (~2–4 targeted fetches) plus model knowledge. Claims fetched from live 2026 pages are cited inline / in per-platform Sources. Claims carried from knowledge that were not re-fetched under the budget are flagged [unverified-2026, from knowledge] — confirm those against current docs before any decision rests on them. This is a critical dossier, not marketing copy: gaps are called out plainly.

TL;DR ranking for *our* stack (Postgres-native, self-hosted, EU):

1. Supabase — the only genuinely Postgres-native, self-hostable, EU-friendly BaaS; its weak spots (OTel, reranker, flags, blue-green) are exactly our backlog, so it's a reference, not a replacement.
2. Encore — best patterns to steal (infra-from-code, built-in distributed tracing w/ OTel export, typed client codegen) but Go/TS, not Rust.
3. Convex — owns the best durable-workflow + scheduler design and built-in vector search; study the model.
4. Laravel — the batteries-included reference (Pennant / Queues+Horizon / Context / Scheduler) we already cross-referenced; highest-leverage primitives to port.

• Disqualified for us by architecture: Firebase (Google-only, can't self-host), Appwrite (MariaDB not Postgres, no vector), PocketBase (SQLite single-node), Xata (DB-branching only, dropped everything else), Hasura/Nhost (GraphQL-first, conflicts with REST/sqlx).

Supabase

Positioning + language/runtime. The "open-source Firebase alternative" built squarely on Postgres. Everything is a thin, opinionated layer over a real Postgres instance — you get the actual SQL engine, not an abstraction. App-side you talk to it via auto-generated REST (PostgREST) and client SDKs (JS/TS, Python, Dart, Swift, Kotlin). Edge Functions run on Deno (TypeScript/JavaScript). Control plane/services are Elixir/TS/Go internally, but as a consumer you live in Postgres + SQL + Deno.

Pricing / OSS model. Genuinely OSS core (Apache-2.0 / MIT across repos) and fully self-hostable via Docker Compose or Kubernetes/Helm. Cloud tiers: Free $0 (500 MB DB, 50K MAU, 1-day log retention, no backups/PITR), Pro $25/mo per project (8 GB disk included then $0.125/GB, 100K MAU, 7-day backups, 7-day logs), Team $599/mo (14-day backups, 28-day logs, SOC 2 + ISO 27001 included), Enterprise custom (90-day logs, HIPAA add-on). The self-hosted OSS build does not include managed read replicas, the advisor/observability dashboards, or branching automation — those are cloud-platform features.

Feature inventory (14 dimensions):

1. Database — YES, real Postgres. RLS-native is the headline: Row-Level Security is the core auth/multi-tenancy primitive and the entire client model assumes it. Branching YES (any plan, billed ~$0.01344/branch/hr on cloud; new branches start empty to protect prod). PITR PARTIAL — paid add-on (~$100/mo per 7 days retention, Pro+ only). Backups YES (7-day Pro, 14-day Team; none on Free).
2. API layer — Auto-REST via PostgREST (instant CRUD from schema). GraphQL YES via pg_graphql. Typed client codegen YES — supabase gen types typescript generates TS types from the live schema. Strong TS story; no first-class typed SDK for arbitrary languages beyond TS.
3. Real-time — YES. Postgres logical-replication change feeds (postgres_changes), plus Broadcast and Presence channels. Known fan-out/scaling caveats at high write volume.
4. Storage — S3-compatible API YES. Image transforms YES (on-the-fly resize/format). CDN YES (Smart CDN on cloud); self-hosted CDN is your problem.
5. Serverless / jobs — Edge Functions (Deno) all tiers. Cron YES via pg_cron. Durable queue YES via `pgmq` (Postgres-backed queue, "Supabase Queues"). No infra-from-code model.
6. Vector / AI — pgvector YES (free on all tiers), HNSW + IVFFlat. Hybrid search PARTIAL — pgvector + Postgres FTS (tsvector) combined in SQL, a recipe you assemble, not turnkey. Reranking NO native reranker (BYO external model).
7. Auth — YES, built-in (GoTrue): email/password, magic link, OAuth, phone/OTP, MFA. SSO (SAML) YES on Pro+. SCIM NO.
8. Observability — PARTIAL. Cloud Logs Explorer, Reports, Advisors, query performance. OTel auto-tracing NO — no first-class OpenTelemetry export of app traces; you instrument your own. Real gap for an OTel-centric shop.
9. Multi-tenancy — RLS-based logical multi-tenancy is canonical (tenant_id + policies). No managed per-tenant DB isolation; project = tenant for hard isolation (doesn't scale cheaply to many tenants).
10. DX — Strong. supabase CLI = full local stack (Docker), migrations (SQL files, db push/diff), seeds, TS codegen; branching ties into Git/PR. One of the better DX stories here.
11. Feature flags — NO built-in flag service. Roll your own (config table + RLS) or third party. [unverified-2026, from knowledge]
12. Edge / functions — Edge Functions on Deno, global edge runtime on cloud; self-host runs them as a container.
13. Deployment — Self-host real (Docker Compose / Helm). Zero-downtime / blue-green is NOT a managed primitive — branching + migrations help staging, but cutover is on you for self-host; cloud upgrades can incur brief restarts.
14. Security / compliance — SOC 2 + ISO 27001 (Team+), HIPAA add-on. EU data residency on cloud (region selection at project creation).

Self-hostable? YES, fully. EU residency? YES — EU region on cloud, or self-host on Hetzner.

Top 3 differentiators: (1) It's actually Postgres — sqlx/SQL knowledge and tooling transfer 1:1; (2) RLS-native security; (3) pgvector + branching + CLI local stack = most "developer-platform"-feeling of the BaaS set. Top 3 gaps: (1) No native OTel tracing / weak app-level observability; (2) no native reranker, DIY hybrid search; (3) no feature flags, no SCIM, no managed blue-green.

Sources: supabase.com/pricing · supabase.com/docs/guides/platform/branching · supabase.com/modules/vector · supabase.com/docs/guides/database/extensions/pgvector

Firebase

Positioning + language/runtime. Google's mobile/web BaaS, now repositioned as an AI-app platform. Polyglot client SDKs (JS/TS, Swift, Kotlin/Java, Dart/Flutter, Unity, C++). Backend logic = Cloud Functions (Node.js, Python, Go-via-Cloud-Run) on Google Cloud. The 2026 story leans on Genkit (AI framework) and Data Connect (managed Postgres). Fundamentally a Google-Cloud-only, proprietary, closed-source platform — there is no self-hosted Firebase (Genkit, the AI framework, is the one OSS, portable exception).

Pricing / OSS model. No OSS core, not self-hostable. Spark (Free) — generous quotas (50K Firestore reads/day, 20K writes/day, 1 GiB storage, 2M Functions invocations/mo, 10 GiB egress/mo). Blaze (pay-as-you-go) — Spark quotas then metered (~$0.18/100K reads, ~$0.18/100K writes, ~$0.26/GB stored; Functions ~$0.40/M invocations). No flat "Pro" price; the known risk is a runaway Blaze bill at scale.

Feature inventory (14 dimensions):

1. Database — Primary stores are NoSQL: Firestore (document) and Realtime Database (JSON tree). Postgres now via Data Connect (managed Cloud SQL + GraphQL layer) — a separate product, not the default. RLS NO; access control via Security Rules (declarative rules language), not row-level SQL. PITR YES (Firestore 7-day; Cloud SQL). Backups YES (Google-managed). Branching NO.
2. API layer — No auto-REST-from-schema like PostgREST; consume Firestore via SDKs. GraphQL only through Data Connect. Typed codegen PARTIAL — Data Connect generates typed SDKs from GraphQL; Firestore itself is schemaless (typing is convention-driven).
3. Real-time — YES, best-in-class. Firestore/RTDB real-time listeners are the original selling point. Presence PARTIAL (RTDB onDisconnect DIY pattern; no first-class presence API).
4. Storage — Cloud Storage (backed by GCS). NOT S3-API-compatible (GCS API). Image transforms PARTIAL (via the "Resize Images" Extension). CDN YES (Firebase Hosting + Google CDN).
5. Serverless / jobs — Cloud Functions (event + HTTP). Cron YES (scheduled functions via Cloud Scheduler). Durable queue YES — Cloud Tasks integration (durable, retried). Infra-from-code PARTIAL (deploy config, not Pulumi-style).
6. Vector / AI — The 2026 push. Vector search YES (Firestore native vector indexing / findNearest). Genkit (OSS; TS/Go/Python-preview/Dart-preview) = RAG, tool-use, agentic flows, unified model access (Gemini, OpenAI, Anthropic Claude, xAI, DeepSeek, Ollama). Hybrid search PARTIAL (vector + filters; no turnkey BM25+vector fusion). Reranking PARTIAL (via Vertex AI ranking, not a one-line Firebase primitive).
7. Auth — YES, mature (Firebase Auth / Identity Platform): email, phone, OAuth, anonymous, MFA. SSO (SAML/OIDC) YES via Identity Platform (paid Auth tier). SCIM PARTIAL (via Cloud Identity Platform, not Firebase-native).
8. Observability — Strong, Google-flavored. Crashlytics, Performance Monitoring, Analytics; functions emit to Cloud Logging/Monitoring and Cloud Trace (OTel-compatible). Genkit emits OpenTelemetry traces for AI flows. So OTel YES — but it lands in Google Cloud Trace, not portable to your own collector without config.
9. Multi-tenancy — YES, first-class: Identity Platform multi-tenancy (tenant-scoped users) is a genuine differentiator. Data isolation still via Security Rules / collection partitioning.
10. DX — Firebase CLI + Emulator Suite (local Firestore/Auth/Functions/Storage) is excellent. Genkit has a local dev UI. No SQL-migration story (schemaless); Data Connect adds schema/migrations for its Postgres.
11. Feature flags — YES (closest in this whole dossier alongside Laravel): Remote Config is a real, free, server-driven config/flagging system with conditions, targeting, and A/B Testing. A genuine differentiator.
12. Edge / functions — Functions run in GCP regions (not a global edge runtime). App Hosting + Hosting CDN serve at edge, but compute is regional.
13. Deployment — No self-host path at all. Zero-downtime is Google-managed; no blue-green primitive you operate.
14. Security / compliance — Inherits GCP: SOC 1/2/3, ISO 27001/27017/27018, HIPAA (with BAA), GDPR. EU residency PARTIAL — Firestore/Cloud SQL support EU regions, but some Firebase services + Auth metadata aren't region-pinnable; weaker than self-hosting. [unverified-2026 on exact per-service residency, from knowledge]

Self-hostable? NO — Google Cloud only, closed source (Genkit is the one OSS piece). EU residency? Partial/per-service; not equivalent to owning the box.

Top 3 differentiators: (1) Best-in-class real-time + Genkit AI framework (multi-model, OSS, OTel traces); (2) Remote Config = genuine built-in feature flags + A/B testing; (3) first-class multi-tenancy via Identity Platform + mature mobile SDKs. Top 3 gaps: (1) Cannot self-host — disqualifying for an EU/Hetzner self-hosted Rust shop; (2) NoSQL-first + Security Rules instead of SQL/RLS (Postgres only via the bolted-on Data Connect); (3) usage-metered Blaze billing is unpredictable and vendor-locks you into GCP.

Sources: firebase.google.com/pricing · firebase.google.com/docs/projects/billing/firebase-pricing-plans · genkit.dev · firebase.google.com/docs/storage/faqs-storage-changes-announced-sept-2024

Appwrite

Positioning + language/runtime. Open-source, self-hostable "Firebase alternative" with a broad product surface (Auth, Databases, Storage, Functions, Messaging, Realtime, Sites web hosting, Avatars). Written primarily in PHP (server) backed by MariaDB + Redis, packaged as a Docker Compose stack. Client SDKs cover 25+ platforms; Functions run user code in 30+ language runtimes (Node, Python, PHP, Ruby, Go, Rust, Deno, Dart, Java, .NET, Swift, etc.).

Pricing / OSS model. True OSS core (BSD-3-Clause) and the cleanest self-host story here — docker compose up brings up server + MariaDB + Redis + functions executor; runs on a $10–20 VPS for small loads. Cloud tiers: Free $0 (75K MAU, unlimited projects), Pro $15/mo per org member, Scale $599/mo (dedicated resources, SOC 2), Enterprise custom. Self-host = free beyond your own infra.

Feature inventory (14 dimensions):

1. Database — NOT Postgres — document-style collections (now "tables/rows") on MariaDB. Relationships, indexing, queries, pagination. RLS-native NO (access control is per-document/collection permissions — role/user/team scoped — not SQL row policies). Branching NO. PITR NO (self-host: your own MariaDB backups). Backups PARTIAL (cloud yes; self-host on you). Weakest database story for a Postgres-native client.
2. API layer — Auto REST and GraphQL YES over your collections. Typed codegen PARTIAL — SDKs typed per-platform, no "generate types from my schema" pipeline as rich as Supabase's.
3. Real-time — YES (WebSocket subscriptions to any Appwrite event). Presence NO first-class presence/broadcast channel API.
4. Storage — File storage with encryption, compression, and real-time image transformations (resize/crop/format via query params) YES — a genuine strength. S3-compatible PARTIAL — pluggable storage backends (local, S3, DO Spaces) but does not expose an S3-compatible API to your app. CDN NO built-in (front it with Cloudflare yourself).
5. Serverless / jobs — Functions (30+ runtimes), event-triggered or scheduled (cron) YES. Durable queue PARTIAL — internal Redis-backed queues for its own workers; no user-facing durable job-queue product. Infra-from-code NO.
6. Vector / AI — NO native vector store today. Vector stores + LLM integrations are on the roadmap, not shipped. Hybrid search / reranking NO. Biggest gap for AI/RAG — run vectors elsewhere.
7. Auth — YES, strong: 30+ OAuth providers, email/phone/magic-link/anonymous, MFA, Teams (built-in org/role model). SSO (SAML) PARTIAL/enterprise. SCIM NO. The Teams model is a nice multi-tenant building block.
8. Observability — WEAK. Function execution logs + basic usage dashboards. OTel auto-tracing NO. Real gap for an OTel-centric stack.
9. Multi-tenancy — Built-in Teams + per-document permissions give a reasonable logical multi-tenant model; no hard per-tenant DB isolation.
10. DX — Good self-host DX (one Docker command, identical across OSes), CLI for deploys/functions, console UI. Migrations PARTIAL (schema via console/CLI/API; not SQL-file migrations). Local stack = just run the real stack in Docker.
11. Feature flags — NO built-in feature-flag product. [unverified-2026, from knowledge]
12. Edge / functions — Functions run in your region/container; no global edge runtime.
13. Deployment — Best self-host path here (Docker Compose / Kubernetes / Swarm). But zero-downtime / blue-green is on you, and major-version upgrades have historically needed migration care. No managed blue-green primitive.
14. Security / compliance — SOC 2 on Scale (cloud). Self-host = your posture. EU residency YES trivially (self-host on Hetzner; cloud region options exist).

Self-hostable? YES — strongest, simplest self-host story here. EU residency? YES — self-host on Hetzner, full control.

Top 3 differentiators: (1) Easiest genuine self-host (single Docker command, OSS); (2) broadest built-in product surface in one box (Auth + DB + Storage + Functions + Messaging + Sites + image transforms); (3) 30+ function runtimes + built-in Teams multi-tenancy. Top 3 gaps: (1) MariaDB, not Postgres — clashes with a sqlx/Postgres-native stack, no RLS; (2) no vector/hybrid search/reranker (roadmap only) — non-starter for RAG without a sidecar; (3) no OTel tracing, no feature flags, no durable user-facing job queue, no managed blue-green — thin operational/observability surface.

Sources: appwrite.io/pricing · github.com/appwrite/appwrite · betterstack.com/community/guides/databases/appwrite-self-hosted · appwrite.io/docs

Convex

Positioning + language/runtime. A "reactive backend-as-a-service" — a managed database plus a serverless function layer where you write pure TypeScript (queries, mutations, actions) running server-side in a V8 isolate. The pitch is end-to-end reactivity: queries are reactive by default; any client subscribed to a query re-renders when underlying data changes. Strong consistency (serializable transactions) is core. Increasingly marketed as "the backend building blocks for your agents" — an AI-app substrate (durable workflows + vector search + scheduler). The backend itself is mostly Rust with a TS function runtime.

Pricing / OSS model. Cloud-first, but the backend was open-sourced (convex-backend) under FSL-1.1-Apache-2.0 ("fair source" — bans building a competing hosted product, converts to Apache-2.0 after two years). Self-hosting is real but community-supported, not officially SLA-backed (support via a #self-hosted Discord). Self-host runs via Docker or a prebuilt binary, storing data in SQLite (default) or Postgres/MySQL — so on self-host you point it at your own Postgres (Neon, RDS, or Hetzner PG). Cloud: generous free tier; Professional ~$25/seat/mo + usage (function calls, DB/vector bandwidth, storage). Startup program: up to 1 yr free Pro. Enterprise (SSO, audit, compliance, SLA) in progress.

Feature inventory (14 dimensions):

1. Database — Convex's own document-relational store (not raw Postgres; Postgres/MySQL/SQLite is only the backing engine on self-host). RLS-native NO — access control enforced in function code, not row-level DB policies. Branching/PITR/backups: PARTIAL — cloud has automatic backups; PITR/branching not a first-class published self-host feature. [unverified-2026, from knowledge]
2. API layer — YES, strong. No REST/GraphQL schema to write; call typed TS functions. Typed client codegen (convex/_generated) gives end-to-end TS types schema→client; generated React/Svelte/etc. hooks. Top differentiator.
3. Real-time — YES, native. Reactive query subscriptions are the core model; clients auto-update. Presence PARTIAL (buildable via reactive docs / a presence component, not turnkey). [unverified-2026]
4. Storage — YES. Built-in file storage with upload URLs + serving. S3-compatible / image transforms / CDN PARTIAL/NO — files stored/served by Convex; no built-in transform pipeline or first-class CDN edge config. [unverified-2026]
5. Serverless / jobs — YES, a real strength. Built-in scheduler (run functions later), cron, and durable workflows (@convex-dev/workflow component) that survive restarts and retries — durable, journaled, exactly-once-ish orchestration of multi-step / multi-day flows. The most "adoptable concept" here for us (see closing section).
6. Vector / AI — YES, built-in vector search (vector indexes on a table, queried inside actions). Full-text search also built-in. Hybrid search (vector + keyword fusion) / reranking PARTIAL/NO as turnkey (you combine vector + text yourself; no built-in reranker). [unverified-2026]
7. Auth — PARTIAL. Convex Auth (library) + first-class integrations with Clerk/Auth0/WorkOS. No built-in SCIM/enterprise SSO in core; bring an IdP. [unverified-2026]
8. Observability — PARTIAL. Dashboard shows function logs, metrics, a call inspector. Auto-OTel tracing NO as a headline (log-stream / exception-reporting integrations exist). [unverified-2026]
9. Multi-tenancy — PARTIAL. No built-in tenant primitive; model tenant-scoping in schema + enforce in functions. One deployment per app is the isolation unit.
10. DX — Excellent. npx convex dev runs a local reactive backend with hot schema/codegen; migrations are schema-push style (no hand-written SQL migrations). Typed codegen automatic.
11. Feature flags — NO built-in (model in DB or use a 3rd-party). [unverified-2026]
12. Edge / functions — Functions run in Convex's V8 isolates (not a deploy-to-edge-POP model); HTTP actions exist for webhooks/REST endpoints.
13. Deployment — Cloud push (convex deploy) instant/atomic. Self-host exists (Docker/binary + your Postgres). Zero-downtime: cloud deploys atomic; self-host blue-green is your responsibility.
14. Security/compliance — Cloud: SOC 2 (Type II) commonly cited; EU residency / enterprise compliance (SSO, audit) is the in-progress Enterprise tier. [unverified-2026]

Self-hostable? YES (Docker/binary, OSS backend, your own Postgres/MySQL) but officially "not supported." EU residency? Self-host = full region control (Hetzner-friendly); cloud EU residency is enterprise-gated.

Top 3 differentiators: (1) End-to-end reactive queries + automatic typed TS codegen — best-in-class DX; (2) built-in durable workflows + scheduler + cron as a coherent unit; (3) built-in vector + full-text search in the same store, no extra infra. Top 3 gaps: (1) Not Postgres-native — no RLS, no SQL, data lives in Convex's model (lock-in risk despite OSS); (2) self-host is community-grade, no OTel/enterprise observability; (3) no built-in feature flags, no turnkey reranker/hybrid-search, weak multi-tenancy primitive.

Sources: news.convex.dev/convex-goes-open-source · github.com/get-convex/convex-backend · docs.convex.dev/self-hosting · stack.convex.dev/self-hosted-develop-and-deploy · convex.dev · srvrlss.io/provider/convex

Hasura

Positioning + language/runtime. A data API engine: point it at one or more databases and it generates a unified GraphQL (and REST) API with fine-grained permissions, no resolvers. v3 / Hasura DDN (Data Delivery Network) re-architected this around data federation — composing many data sources into a single "supergraph." The v3 engine is Rust; custom logic via TypeScript/Python/Go connector SDKs. Sources: PostgreSQL (+ flavors), MongoDB, ClickHouse, MS SQL Server, more via connectors.

Pricing / OSS model. Mixed-source. The v3 engine is open-sourced (Apache-2.0), and data connectors (Postgres, ClickHouse, Turso, DuckDB, Qdrant, etc.) are OSS — but the DDN CLI, web console, and LSP are proprietary. The classic v2 GraphQL Engine remains OSS (Apache-2.0) and Docker-self-hostable (Community Edition), with a self-hosted Enterprise Edition. DDN pricing is model-based: free for low traffic; Advanced ~$30 per active model/mo (active = >1000 hits/mo) incl. federation/collab; Private DDN ~$1,000 per availability zone/mo for BYOC/self-hosted data plane + HIPAA.

Feature inventory (14 dimensions):

1. Database — YES, Postgres-native (+ other sources). RLS-native PARTIAL — Hasura enforces its own role/row/column permission layer at the engine (declarative, session-variable based), distinct from native PG RLS but functionally row-level. Branching/PITR/backups: NO — Hasura is an API layer over your DB; backups/PITR are the database's job.
2. API layer — YES, the core competency. Auto GraphQL + REST (REST endpoints derived from GraphQL ops). Typed client codegen YES via the GraphQL ecosystem (GraphQL Codegen) rather than a proprietary client.
3. Real-time — YES in v2 (GraphQL subscriptions over websockets, live queries, plus event/scheduled triggers). In DDN/v3, subscription support arrived later / has been more limited — verify for your version. Presence NO. [unverified-2026]
4. Storage — NO. No object storage / image transforms / CDN — out of scope; bring S3/MinIO yourself.
5. Serverless / jobs — PARTIAL. v2 has event triggers (DB-change webhooks), scheduled triggers (cron-like), and Actions (call your own logic). No durable-workflow engine, no infra-from-code. DDN adds custom logic via connectors.
6. Vector / AI — PARTIAL. Via the Qdrant connector (and pgvector through the Postgres connector) you can expose vector data in the supergraph; hybrid search / reranking is NOT built-in (you federate a vector store). [unverified-2026]
7. Auth — PARTIAL/strong on authz. Built-in JWT / webhook auth + role-based permission system; integrates with any IdP (Auth0/Clerk/Cognito). Console SSO + SCIM are Enterprise/Cloud features; it does not issue identities itself.
8. Observability — YES (Enterprise/Cloud). OpenTelemetry traces/metrics export, query analytics. Open-source CE has lighter observability.
9. Multi-tenancy — PARTIAL/good. Role + session-variable permissions make per-tenant data isolation natural; multiple projects/supergraphs for hard isolation. No turnkey "tenant" object.
10. DX — Good. DDN CLI builds metadata locally; run the full stack with Docker Compose or Kubernetes without deploying to cloud. Declarative metadata (YAML) + migrations tooling (v2 had a solid migration/metadata system).
11. Feature flags — NO built-in.
12. Edge / functions — DDN is a distributed/edge-ish "delivery network" for the API plane; no general edge-function runtime (business logic lives in connectors).
13. Deployment — Self-host CE/EE (Docker/K8s); DDN cloud or Private DDN (BYOC/VPC). Zero-downtime: metadata reloads are hot; engine is stateless so rolling deploys are straightforward.
14. Security/compliance — Strong. SOC 2, and HIPAA on Private DDN; region/AZ selection on Private DDN supports EU residency.

Self-hostable? YES — v2 CE/EE fully Docker/K8s self-hostable; v3 engine + connectors OSS and runnable via Compose/K8s (CLI/console proprietary). Private DDN runs the data plane in your own VPC/AZ → strong EU residency (Hetzner/self-managed PG works since Hasura just connects to your DB).

Top 3 differentiators: (1) Instant unified GraphQL+REST over existing Postgres with zero resolver code — fastest path to a typed data API over an existing schema; (2) data federation / supergraph across many heterogeneous sources; (3) mature declarative authz (role/row/column permissions) + OTel observability + Postgres-native (no data lock-in — it's your DB). Top 3 gaps: (1) Pure API layer — no storage, no jobs/workflow engine, no infra-from-code; (2) mixed/closed tooling (CLI/console/LSP proprietary) and model-based pricing can get expensive at scale; (3) DDN/v3 subscription + v2-feature parity gaps; GraphQL-first may mismatch a Rust/axum REST stack.

Sources: github.com/hasura/graphql-engine · hasura.io/blog/announcing-open-source-hasura-graphql-engine-v3 · github.com/hasura/graphql-engine/discussions/10556 · hasura.io/blog/for-the-models-that-matter-hasura-ddn-model-based-pricing · hasura.io/products/deployment

Encore

Positioning + language/runtime. "Infrastructure-from-code" for Go and TypeScript: you declare the infra your app needs — SQL databases, Pub/Sub topics, cron jobs, object storage, caches, secrets — as typed objects directly in your application code. Encore parses the code at compile time into an "application model" / infra graph, then provisions the real resources (locally as Docker/in-memory; in the cloud into your own AWS/GCP VPC). Fundamentally a backend microservice framework + platform, not a database product.

Pricing / OSS model. The framework + CLI + local dev tooling are open source (run entirely free, self-host fully). Encore Cloud is the paid layer that automates provisioning/CI-CD/observability into your cloud account. Tiers (2025/2026): Free ($0) for hobby/dev → paid ~$39 tier (per developer), with usage-based cloud/observability on top. Crucially you can skip the platform: encore build docker emits a standard container + you supply your own infra config (Terraform/Pulumi).

Feature inventory (14 dimensions):

1. Database — YES, Postgres-native. Declare a SQL DB in code; Encore provisions PG (Docker locally, Cloud SQL/RDS in cloud) and runs migrations for you. RLS-native NO (standard PG; RLS is your choice). PITR/backups delegated to the managed PG (RDS/Cloud SQL) — inherited, not an Encore primitive.
2. API layer — YES, strong. Define an API by writing a typed Go/TS function with request/response structs; Encore generates the HTTP layer, validation, and typed client SDKs for frontends/other services (codegen). REST-style; GraphQL is not the model.
3. Real-time — PARTIAL. WebSocket/streaming endpoints supported, but no turnkey reactive-subscription or presence system like Convex. Realtime fan-out you build on Pub/Sub. [unverified-2026]
4. Storage — YES (object storage primitive). Declare a Bucket in code → provisions S3/GCS (S3-compatible). Image transforms / CDN NO built-in (use a CDN/transform service yourself). [unverified-2026]
5. Serverless / jobs — YES, a core strength. Pub/Sub topics + subscriptions (provisions SQS/SNS, GCP Pub/Sub, or NSQ locally) and Cron Jobs declared in code. Durable-workflow engine PARTIAL — Pub/Sub + idempotent subscribers give reliable async, but no Convex-style journaled durable-workflow primitive out of the box. Infra-from-code is the headline.
6. Vector / AI — PARTIAL/NO. No built-in vector search; add pgvector to the Encore-managed Postgres yourself. No hybrid search/reranker. [unverified-2026]
7. Auth — PARTIAL. Built-in auth handler pattern (you implement the handler; Encore wires it into every endpoint + propagates auth context across services). Bring your own IdP; no built-in SSO/SCIM. [unverified-2026]
8. Observability — YES, top differentiator. Built-in distributed tracing across services + structured logs + metrics, captured automatically (no manual instrumentation), searchable in the dashboard locally and in Encore Cloud — no separate collector needed. OTel export is supported for shipping to your own stack.
9. Multi-tenancy — PARTIAL. No tenant primitive; achieved via app design (per-tenant schema/row scoping) + multiple environments. Per-service DB isolation is natural.
10. DX — Excellent. encore run spins the whole local stack (DBs in Docker, Pub/Sub in-memory) + a local dev dashboard showing services, APIs, traces, DB browser, Pub/Sub messages, and auto-generated architecture diagrams. Migrations + typed client codegen built in. Preview environment per PR in Encore Cloud.
11. Feature flags — NO built-in. [unverified-2026]
12. Edge / functions — Not an edge-POP model; services run as containers (Cloud Run/Fargate). Standard container output via encore build docker.
13. Deployment — Strong self-host + cloud. Cloud provisions into your AWS/GCP with CI/CD, preview envs, env-sync. Self-host: encore build docker → standard image deployable anywhere with your own Terraform/Pulumi infra. Zero-downtime/blue-green: via the underlying platform (Cloud Run/Fargate rolling) or your orchestrator — not an Encore-specific blue-green primitive, but rolling deploys are default on managed targets. [unverified-2026]
14. Security/compliance — Encore Cloud provisions into your own VPC (data stays in your account); SOC 2 for the platform commonly cited; EU residency = pick the AWS/GCP region (or self-host on Hetzner). [unverified-2026]

Self-hostable? YES, cleanly — framework is OSS and encore build docker produces a vanilla container with no Encore-platform dependency, so you run it on Hetzner / your own Postgres / your own infra config and keep all data in-EU. The Cloud is optional and provisions into your cloud account regardless. Best self-host story for a team already running its own infra.

Top 3 differentiators: (1) Infrastructure-from-code — declare DB/Pub-Sub/cron/buckets/secrets inline, get local Docker + cloud provisioning + an architecture diagram for free; (2) built-in automatic distributed tracing (+ logs/metrics, OTel export) with zero manual instrumentation; (3) typed APIs + generated client SDKs + per-PR preview environments, with a clean self-host/build docker escape hatch (no lock-in). Top 3 gaps: (1) No data-layer products — no vector search, no real reactive realtime/presence, no storage transforms/CDN, no feature flags; (2) no Convex-style durable workflow engine (Pub/Sub + idempotency only); (3) Cloud's deepest value (auto-provision into AWS/GCP) doesn't map onto a Hetzner-only shop — you'd use the OSS framework + tracing, not the Cloud.

Sources: github.com/encoredev/encore · encore.dev/docs/platform/infrastructure/infra · encore.dev/articles/distributed-tracing-microservices · encore.dev/docs/go/self-host/configure-infra · encore.cloud/pricing · g2.com/products/encore-encore/pricing

NestJS

Frameworks, not BaaS — they give you primitives, not managed infra. Read each as "what's native vs what you bolt on."

Positioning + language/runtime. A progressive, opinionated TypeScript framework for Node.js (Express by default, Fastify optional). Its identity is architectural, not infrastructural: it ports Angular-style dependency injection, modules, decorators, providers, guards, interceptors, pipes to the server. It tells you how to organize a backend but ships almost nothing managed. Current line is NestJS 11 (2026) — moved to Express v5 default, modernized microservices/GraphQL transports.

Pricing / OSS model. Fully free MIT OSS. No first-party cloud, no managed adjacent products — the cleanest "pure framework" here. Deploy anywhere Node runs (VPS, Docker, K8s, Lambda via adapter). A paid Devtools UI + courses/consulting exist, but no hosting product. Self-host: always yes.

Feature inventory (14 dimensions):

1. Database — Bolt-on, first-class adapters. No native ORM. Official modules for TypeORM, Prisma, Sequelize, MikroORM, Mongoose. Migrations come from whichever ORM you pick; Nest provides none. Not Postgres-managed.
2. API layer — Strongest of the frameworks. Native REST controllers (decorator routing); first-party `@nestjs/graphql` (code-first or schema-first; v11 added Apollo Server v4 + federation updates); `@nestjs/swagger` auto-generates OpenAPI from decorators; `@nestjs/microservices` gives built-in transports for TCP, Redis, NATS, MQTT, gRPC, RabbitMQ, Kafka. Typed client codegen via OpenAPI/gRPC tooling (bolt-on).
3. Real-time — YES, native. @WebSocketGateway() + @SubscribeMessage() (socket.io or ws), GraphQL subscriptions, SSE via @Sse(). Genuine strength.
4. Storage — NO native filesystem abstraction. No Flysystem equivalent. Bolt on @aws-sdk/client-s3, multer (uploads), sharp (transforms). CDN entirely yours. Clear gap vs Laravel.
5. Serverless/jobs — Bolt-on but official. @nestjs/bullmq (BullMQ over Redis) for durable queues; @nestjs/schedule for cron/intervals (in-process, not distributed — needs leader-election/external lock for multi-instance). No Horizon-equivalent dashboard (use Bull Board separately).
6. Vector/AI — NO native. pgvector via Prisma/TypeORM raw columns/queries. No AI primitives; LangChain.js etc. pure bolt-on.
7. Auth — Bolt-on via `@nestjs/passport` + Passport strategies + `@nestjs/jwt`. No batteries-included auth scaffold (no Breeze/Fortify equivalent). Guards make RBAC clean; login/session/refresh/password-reset wired by you. SSO/SAML/SCIM third-party.
8. Observability — Mostly manual. No first-party APM. @nestjs/terminus (health checks). OTel via community nestjs-otel — v11 auto-propagates trace IDs across Kafka/RabbitMQ/gRPC transports (real improvement). No Telescope/Pulse equivalent.
9. Multi-tenancy — Manual. Request-scoped providers + custom middleware make per-tenant DI feasible, but no tenancy package; connection-switching is yours.
10. DX — Strong. @nestjs/cli scaffolds modules/controllers/services/resources (nest g resource = full CRUD + DTOs + tests). Excellent testing (@nestjs/testing, DI-mockable). TS end-to-end.
11. Feature flags — NONE native. Bolt-on (Unleash SDK, OpenFeature, ConfigCat). No Pennant equivalent.
12. Edge/functions — NO. Node-server model; no edge runtime (Lambda/Cloud Functions via serverless adapters).
13. Deployment — Self-host always; Docker/K8s-friendly. No first-party deploy product — zero-downtime is your job (PM2/rolling/K8s). Most infra-neutral framework here.
14. Security/compliance — Framework-level: helmet, @nestjs/throttler (rate limit), CSRF via middleware, class-validator, guards. CSP/HSTS via helmet. Compliance entirely yours.

Self-hostable? EU residency? Yes/yes — it's your infra; zero vendor lock-in (no first-party cloud to avoid).

Top 3 differentiators: (1) Best-in-class modular DI architecture + testability for large teams; (2) first-party multi-protocol (REST + GraphQL + gRPC + 7 microservice transports + WS/SSE) under one mental model; (3) TypeScript end-to-end with strong codegen (OpenAPI/gRPC). Top 3 gaps: (1) No batteries — no native ORM, storage, auth scaffold, queue dashboard, feature flags, or observability; everything is assembled; (2) no first-party deploy/ops story; (3) in-process scheduler doesn't safely fan out across replicas without external locking.

Sources: docs.nestjs.com/websockets/gateways · medium.com/@atillataha/nestjs-11-new-features · dragonflydb.io/guides/bullmq-nestjs · tech-insider.org/nestjs-vs-nextjs-2026

Laravel (v11/12)

Positioning + language/runtime. The batteries-included full-stack PHP framework (PHP 8.2+). Current GA is Laravel 12 (11.x still widely deployed; 13.x docs published). The opposite philosophy to NestJS: where Nest gives structure-only, Laravel ships managed-feeling primitives natively — ORM, migrations, queues, scheduler, auth, storage, cache, events, broadcasting, feature flags, observability — all first-party. This is exactly the "batteries-included" model we want to study. Runs on PHP-FPM, or Octane (Swoole/RoadRunner/FrankenPHP) for persistent-worker performance.

Pricing / OSS model. Framework is free MIT OSS. Paid adjacent products (all optional; framework works fully without them): Laravel Cloud (managed Laravel-native PaaS; usage-based, $5/mo credits, ~$20/mo small apps; bundles managed Postgres/storage/cache/queues), Forge (VPS provisioner — Nginx/SSL/queue workers/scheduler/zero-downtime deploys on DigitalOcean/AWS/Linode/Vultr/Hetzner), Vapor (serverless on Lambda, $39/mo + AWS), Nova (paid admin), Nightwatch (paid production observability), Envoyer (zero-downtime deploy, now folded into Cloud/Forge). Self-host: always yes — vanilla PHP-FPM, no Laravel product required.

Feature inventory (14 dimensions):

1. Database — Native, best-in-class. Eloquent ORM (active-record) + query builder + first-party migrations & schema builder + seeders + factories. MySQL/MariaDB/Postgres/SQLite/SQL Server. Not a managed DB, but the migration/ORM ergonomics are the gold standard the other two emulate.
2. API layer — REST via controllers + API Resources (transformer layer) + form requests (validation). No first-party GraphQL (community Lighthouse). OpenAPI via Scribe. Sanctum issues API tokens. Weaker GraphQL story than NestJS, stronger REST ergonomics.
3. Real-time — YES, native, first-party. Reverb (Laravel's own PHP WebSocket server), broadcasting events, Echo JS client. Also Pusher/Ably drivers. Genuinely batteries-included real-time.
4. Storage — Strongest of the frameworks. Filesystem abstraction over Flysystem with unified API across local, S3, FTP, SFTP drivers; signed/temporary URLs; streaming; first-party. Image transforms via Intervention (community); CDN config is yours. The model to study.
5. Serverless/jobs — KEY STRENGTH. Native Queues (Redis/database/SQS/Beanstalk drivers), `php artisan schedule` Scheduler (cron in code, single crontab entry), and Horizon (first-party Redis-queue dashboard: real-time throughput, failed jobs, wait times, retries, tags, worker autoscaling). Durable, retriable, batchable jobs (Bus::batch), job chaining, rate-limiting, unique jobs. Detailed below.
6. Vector/AI — No native AI. pgvector via Eloquent raw/casts or community packages; Scout gives first-party full-text search abstraction (Algolia/Meilisearch/Typesense/database drivers) — closest native "search" primitive.
7. Auth — Strongest, multi-tier, native. Breeze (starter scaffold), Fortify (headless auth backend), Sanctum (SPA/API tokens), Passport (full OAuth2 server), Socialite (social login). Built-in hashing, password reset, email verification, MFA, gates/policies. SSO/SAML/SCIM = community/Cloud. No other framework here ships this breadth.
8. Observability — Native, multi-tool. Telescope (dev debugger: requests, queries, jobs, logs, mail, cache), Pulse (production metrics dashboard, ships with 11+), Context (request→job trace context, below), Nightwatch (paid full APM). OTel via community (opentelemetry-laravel, Uptrace). Best out-of-box observability of the frameworks.
9. Multi-tenancy — Mature community packages (stancl/tenancy, Spatie multitenancy) — single-DB or DB-per-tenant, automatic connection switching, tenant-aware queues/cache. Not core, but a well-trodden path.
10. DX — Exceptional. Artisan CLI scaffolds everything; Sail (Docker dev env), Tinker (REPL), Pint (formatter), Pest/PHPUnit. Migrations + factories + seeders are the DX benchmark.
11. Feature flags — `Pennant` is BUILT-IN & first-party. Detailed below. No other framework here has native feature flags.
12. Edge/functions — NO edge runtime. PHP-FPM/Octane server model; Vapor gives serverless (Lambda), not V8-edge.
13. Deployment — Self-host always (PHP-FPM/Nginx). Best first-party deploy ecosystem: zero-downtime via Cloud / Forge / Vapor / Envoyer. Forge explicitly supports Hetzner.
14. Security/compliance — Framework-level: CSRF tokens native, XSS escaping in Blade, encrypted cookies, hashed passwords, rate limiting, signed URLs, policies/gates. CSP via community (spatie/laravel-csp). Compliance is yours.

SPECIAL FOCUS — the batteries OpenAliceLabs wants to learn from

Pennant (feature flags) — first-party. Define a feature with a resolver closure scoped to any object (typically the user): Feature::define('new-api', fn (User $u) => $u->isInternalTeamMember()). Check with Feature::active('new-api') or the @feature Blade directive / route middleware. Resolved values are stored (default database driver; also in-memory array driver) so a user gets a stable assignment — enabling gradual rollout, A/B tests, trunk-based dev. Supports rich values (not just booleans — return a variant string), scoping to any model, purging/activating in bulk via Artisan, and lottery/percentage rollout via resolver logic. Lesson for a Rust/axum shop: a tiny define-resolver + persistent-store + stable-bucketing API is a very high-leverage primitive.

Queues / Horizon (durable jobs). Queues are a driver abstraction (Redis/DB/SQS). Jobs are classes implementing ShouldQueue; support retries/backoff, batches (Bus::batch()->then()->catch()->finally()), chains, unique-job locks, rate limiting, middleware. Horizon is a first-party Redis dashboard: real-time throughput, runtime/wait metrics, failed-job inspection + retry, tags, and automatic worker autoscaling by queue load. Lesson: the durable-job + visible-dashboard + autoscaling triad is what makes background work operable, not just possible.

Context (request-scoped context for tracing/logging) — directly relevant to axum tracing. Context captures key/value data that (a) is auto-appended as metadata to every log line in the request, and (b) survives the HTTP→queued-job boundary — data is dehydrated into the job payload on dispatch and hydrated back when the worker runs, so a trace_id set in middleware appears in logs emitted by the eventual background job. API: add/addIf/when/increment/decrement, get/only/except/pull/remember/all, has/missing/forget, stacks (push/pop/stackContains — e.g. push every query SQL+duration as breadcrumbs), hidden context (addHidden/... — carried across the job boundary but NOT logged, e.g. locale/secrets), a `scope()` helper for temporary per-callback context, and `dehydrating`/`hydrated` events to hook the boundary. Lesson for axum/tokio: this is essentially a structured task-local / tracing-span propagation layer with a clean ergonomic API — the "dehydrate into the job, rehydrate on the worker, auto-attach to logs" pattern is the load-bearing idea; in Rust it maps to tracing spans + task-local context serialized onto enqueued jobs.

Scheduler. Cron defined in code (Schedule::command('report:send')->dailyAt('13:00')), driven by one system crontab entry (schedule:run every minute). Supports ->everyFiveMinutes(), timezones, overlap prevention (withoutOverlapping), single-server locking across a fleet (onOneServer), background running, maintenance-mode skipping, before/after/failure hooks. Lesson: code-defined schedules + built-in single-server locking solves the multi-replica cron problem that NestJS's in-process scheduler leaves to you.

Self-hostable? EU residency? Yes/yes. Vanilla PHP-FPM on Hetzner/EU is the default; Forge manages Hetzner directly; zero lock-in if you skip the paid products.

Top 3 differentiators: (1) Truly batteries-included — ORM+migrations, queues+Horizon, scheduler, auth (5 packages), storage abstraction, broadcasting, Pennant, Context, Telescope/Pulse all first-party; (2) best deploy/ops ecosystem (Cloud/Forge/Vapor/Envoyer; Hetzner-supported); (3) operability primitives (Horizon dashboard, Pulse, Context-driven tracing) that make background/observability work visible. Top 3 gaps: (1) PHP runtime ceiling — request-per-process; needs Octane (Swoole/FrankenPHP) to approach Node/Rust concurrency, which adds state-leak footguns; (2) no native GraphQL / weaker typed-API codegen vs NestJS; (3) no edge runtime; no native vector/AI (pgvector + AI are bolt-on).

Sources: laravel.com/docs/12.x/context · laravel.com/docs/12.x/horizon · laravel.com/docs/12.x/pennant · laravel.com/docs/12.x/telescope · curotec.com/insights/laravel-cloud-vs-forge-vs-vapor · laravel.com/cloud/pricing

Next.js (App Router as backend)

Positioning + language/runtime. A React meta-framework (TypeScript/JS on Node, plus a V8-isolate Edge runtime). Using its App Router as a backend means leaning on React Server Components (RSC), Route Handlers (app/**/route.ts — REST endpoints), and Server Actions ('use server' async functions callable directly from components as secure RPC mutations). It is a frontend-first framework retrofitted as a backend — excellent for app-coupled data/mutations, not designed as a standalone API platform. Current line is Next.js 15 (16 emerging). Tightly co-evolved with Vercel (its commercial host).

Pricing / OSS model. Framework is free MIT OSS. The paid adjacent product is Vercel (host built by Next's authors): generous Hobby free tier, Pro ~$20/user/mo + usage (functions, edge, bandwidth, cron, KV/Postgres add-ons). No first-party ORM/queue/auth products — Vercel sells infrastructure, not framework batteries. Self-host: yes (next start / Docker / OpenNext for non-Vercel), though some features (ISR, image optimization, edge, cron) are smoother on Vercel.

Feature inventory (14 dimensions):

1. Database — No native ORM/migrations. Bolt-on Prisma or Drizzle (Drizzle popular for edge). Call the DB from Server Components, Route Handlers, or Server Actions. Migrations come from the ORM. Not Postgres-managed (Vercel Postgres/Neon is a separate add-on).
2. API layer — Route Handlers give REST (GET/POST/... exports per route). Server Actions give typed RPC-style mutations callable directly from React (no manual fetch wiring) — the most ergonomic mutation story here for app-coupled UIs, but app-bound, not a general public API surface. No native GraphQL. Typed "client" = direct function import (Server Actions) rather than codegen.
3. Real-time — NONE native. No WebSocket server (serverless/edge model is hostile to long-lived sockets). SSE possible via a streaming Route Handler, but persistent realtime needs a bolt-on (Pusher/Ably/Soketi or a separate WS service). Clear gap vs NestJS gateways / Laravel Reverb.
4. Storage — No native filesystem abstraction. next/image does image optimization/transforms (a genuine native strength, best-on-Vercel). File storage = bolt-on (Vercel Blob, S3 SDK). CDN = Vercel/your CDN.
5. Serverless/jobs — NONE native. No durable queue, no in-framework scheduler. Vercel Cron (platform feature, hits a Route Handler on schedule) covers cron if on Vercel; durable background jobs need bolt-on (Inngest, Trigger.dev, QStash, BullMQ + separate worker). Weakest jobs story of the frameworks.
6. Vector/AI — No native vector, but the Vercel AI SDK (ai package, by the same authors) is a strong, popular bolt-on for LLM streaming/tools — arguably the best "adjacent AI" of the frameworks. pgvector via Drizzle/Prisma.
7. Auth — Bolt-on. Auth.js / NextAuth (community, de-facto choice) or Clerk/Lucia/better-auth. No first-party auth. Server Actions + middleware make session checks clean, but you assemble it. SSO/SCIM via Clerk/WorkOS.
8. Observability — OpenTelemetry hooks are native (instrumentation.ts, @vercel/otel); structured well on Vercel. No Telescope/Pulse-style first-party dashboard; production APM = Vercel Observability or bolt-on (Sentry/Datadog).
9. Multi-tenancy — Manual. Middleware + rewrites handle subdomain/path tenancy routing well, but per-tenant data isolation is hand-rolled. No package.
10. DX — Excellent for full-stack-React: create-next-app, fast refresh, file-based routing, colocated server/client. Caching is the notorious DX hazard — Next 15 made fetch/GET-Route-Handlers/client-nav uncached by default (reversing 14's aggressive caching), reducing footguns. Migrations/codegen come from your ORM, not Next.
11. Feature flags — No framework-native flags. Vercel Flags SDK / `flags` package (platform-aligned) is the bolt-on; or OpenFeature/Unleash. No Pennant equivalent.
12. Edge/functions — YES — unique strength. export const runtime = 'edge' runs a route/handler on a V8-isolate edge runtime (sub-ms cold start vs 200–300ms Node), plus Middleware runs at the edge. Neither NestJS nor Laravel has this. Caveat: edge runtime is a restricted API subset (no full Node).
13. Deployment — Self-host (next start/Docker/OpenNext) or Vercel (zero-config, preview deploys, atomic/zero-downtime, global edge). Best preview-deploy DX here; most pull toward a single vendor.
14. Security/compliance — Framework-level: Server Actions are POST-only with built-in origin/CSRF-style protections; secrets stay server-side in RSC/actions; middleware for headers/CSP. Less of a "security toolkit" than Laravel; rate-limiting/WAF are platform/bolt-on. Compliance is yours.

Self-hostable? EU residency? Self-hostable yes (next start/Docker/OpenNext on Hetzner/EU). Caveat: several conveniences (ISR-at-edge, image optimization, edge middleware, cron, Blob/KV/Postgres) are Vercel-optimized; full EU-residency self-host means giving some up or replacing them. The closer you stay to Vercel, the more US-platform coupling — relevant to an EU/Hetzner shop.

Top 3 differentiators: (1) Edge runtime + middleware (V8 isolates, sub-ms cold start) — unique here; (2) Server Actions — typed, zero-boilerplate UI→server mutations; best app-coupled mutation ergonomics; (3) native next/image transforms + Vercel AI SDK as strong adjacent capabilities. Top 3 gaps: (1) Not a real backend platform — no native ORM, auth, durable queues, scheduler, realtime, storage abstraction, or feature flags; a frontend framework with server endpoints; (2) no native realtime / no durable jobs — both require leaving the framework; (3) Vercel gravity — the best ops/cron/edge/observability experience assumes Vercel (US), a friction point for EU-residency self-hosting.

Sources: nextjs.org/docs/app/getting-started/route-handlers · nextjs.org/blog/next-15 · dev.to/alvisonhunter/nextjs-quick-guide-to-server-actions · strapi.io/blog/nextjs-16-route-handlers-explained · pristren.com/blog/nextjs-app-router-patterns-2026

Shorter notes — PocketBase · Nhost · Xata

PocketBase

What it is. A single self-contained Go binary bundling SQLite (embedded), an embedded admin dashboard UI, REST-ish API, realtime (SSE), auth, and file storage. The "backend in one file." As of 2026 a personal OSS project with an intentionally limited scope and an explicit "no maintenance/support promises" disclaimer, still pre-1.0 (v0.39.x) — pin versions. MIT, fully free OSS, no first-party cloud (managed via third parties: PocketHost, Elestio).

• DB: SQLite (YES) / Postgres (NO). Access control via per-collection API rules (PARTIAL; not PG RLS). Branching/PITR NO (file-copy backups, SQLite WAL).
• API: Auto REST YES; GraphQL NO; typed codegen PARTIAL (community TS SDK).
• Real-time: YES (SSE). Storage: local FS or S3-compatible backend YES; image thumbnails/transforms YES; CDN NO.
• Jobs: cron YES (built-in scheduler); durable queue NO. Vector/AI: NO (SQLite FTS5 only if hand-wired). Auth: YES (15+ OAuth, OTP, MFA). Observability: basic logs only (NO OTel). Feature flags: NO. Edge: NO (JS hooks run in-process via Goja). Multi-tenancy: PARTIAL.
• Self-host/EU: maximally self-hostable (one binary on Hetzner). No SOC2 (no vendor).
• Differentiators: (1) radical operational simplicity — zero-dependency single binary; (2) embeddable as a Go framework (extend, not wrap). Gaps: (1) SQLite-only + single-node (no Postgres, no horizontal scale, no DB branching); (2) bus-factor-of-one pre-1.0 with no durable queue, no observability, no vector/search — far from our axum/sqlx/pgvector stack.
• Sources: pocketbase.io/faq · betterstack.com/community/guides/database-platforms/pocketbase-backend · elest.io/open-source/pocketbase · saaslens.app/tools/pocketbase

Nhost

What it is. Open-source Firebase alternative on Postgres: Postgres + Hasura (instant GraphQL) + Hasura Auth + Hasura Storage + serverless Functions (Node/TS) + a CLI for local dev. Largely an integration/packaging + managed hosting layer over Hasura's components. 100% OSS, fully self-hostable via docker-compose. Cloud: Free / ~$25/mo Pro / ~$599/mo Team; PITR a paid add-on (~$100). Recent "Nhost v2" relaunch (new free tier, new SDKs, AWS).

• DB: Postgres YES. RLS PARTIAL (security is primarily Hasura's role/permission layer over GraphQL; you can also use PG RLS). Branching NO; PITR YES (paid).
• API: GraphQL headline (Hasura) — instant API, subscriptions, event triggers, role-based auth YES. REST PARTIAL. Typed codegen YES (strong GraphQL-codegen).
• Real-time: YES (GraphQL subscriptions). Storage: YES (Hasura Storage over S3-compatible backend); transforms PARTIAL (presets); CDN PARTIAL (cloud).
• Jobs: Functions YES; cron + event triggers via Hasura YES; durable queue NO (event triggers approximate it). Vector/AI: PARTIAL — Nhost pushed an "AI"/auto-embeddings (pgvector) feature in cloud; no first-party reranker/hybrid engine. [partly unverified-2026, from knowledge]
• Auth: strong (email/pass, magic links, SMS, OAuth, MFA). Observability: PARTIAL (cloud metrics/logs; no documented OTel export). Feature flags: NO. Edge: PARTIAL (Node functions, not true edge). Multi-tenancy: PARTIAL (Hasura roles).
• Self-host/EU: fully self-hostable OSS; EU regions on cloud + Hetzner self-host both viable. SOC2 not clearly advertised [unverified-2026].
• Differentiators: (1) instant GraphQL + subscriptions + typed codegen out of the box; (2) complete, genuinely self-hostable Firebase-replacement on Postgres. Gaps: (1) GraphQL-first worldview (friction vs REST/sqlx; you inherit Hasura's permission model rather than plain PG RLS); (2) no durable queue, no DB branching, weak OTel, no feature flags — and you operate a multi-container Hasura+auth+storage stack.
• Sources: nhost.io · nhost.io/pricing · github.com/nhost/nhost · nhost.io/blog/nhost-v2 · euro-stack.com/solutions/nhost

Xata — PIVOTED (key honest finding)

What it is in 2026. Xata is no longer the 2022 Airtable-style serverless data platform with built-in Elasticsearch-backed full-text + vector search. Over 2024–2025 it was rebuilt from scratch and in 2026 is a "Postgres platform": 100% vanilla Postgres with copy-on-write branching at the storage layer (NVMe/TCP, scale-to-zero), on Kubernetes. The old branded SDK/search/vector/free-tier product was retired with the pivot. Tagline: "One Postgres, thousands of branches." Core is OSS, Apache-2.0 (self-host the full branching platform free). Cloud is pure usage-based (per-compute-hour + ~$0.28/GB/mo storage); no flat free plan anymore. Also BYOC.

• DB: Postgres YES (vanilla, no fork). RLS YES (real Postgres). Branching YES — copy-on-write, "copy TB in seconds," hundreds of branches without multiplying storage (flagship). PITR YES (to object storage).
• API: It's just Postgres — connect with standard sqlx/pgx. No instant REST/GraphQL, no typed codegen (that was the old Xata; removed). Real-time: NO built-in (use LISTEN/NOTIFY / logical replication). Storage (files): N/A (it's a DB platform). Jobs: scale-to-zero compute YES; durable queue / cron NO built-in (in-DB, e.g. pg_cron).
• Vector/AI: NO first-party vector/hybrid search anymore — the Elasticsearch-backed engine was removed in the pivot. pgvector only because it's plain Postgres (BYO extension). Reranker NO. (Honest key finding — Xata is no longer a search/vector play.)
• Auth / Observability / Feature flags / Edge: NO (it's infrastructure, not an app platform). Multi-tenancy: strong at instance/branch level (cheap per-tenant branches), not app-level.
• DX: excellent for branch-per-env / branch-per-PR (instant ephemeral DBs); PII anonymization on branch creation (sanitize prod into a dev branch) is a documented capability.
• Self-host/EU: YES (Apache-2.0, K8s) but operationally heavy (distributed NVMe/TCP copy-on-write storage on K8s, not a single binary). EU residency via self-host/BYOC. SOC2/EU not clearly stated for the new platform [unverified-2026].
• Differentiators: (1) instant copy-on-write Postgres branching + sub-second clones + PITR — exactly the staging / blue-green / branch-per-PR-with-prod-data capability we flagged, on vanilla Postgres (works with sqlx, no app rewrite); (2) PII anonymization on branch for safe dev data. Gaps: (1) the pivot removed everything BaaS (no search/vector/hybrid/reranker, no REST/GraphQL/codegen, no auth/storage/realtime — it does one thing); (2) operationally heavy to self-host (K8s + distributed storage) and no flat free tier.
• Sources: xata.io · github.com/xataio/xata · xata.io/blog/serverless-postgres-platform · xata.io/blog/open-source-postgres-branching-copy-on-write · xata.io/blog/xata-postgres-with-data-branching-and-pii-anonymization · dev.to/xata (OSS Apache-2.0)

Comparison Table (platforms × dimensions)

Legend: ✅ native/first-class · 🟡 partial / bolt-on / via-extension · ❌ absent · PG=Postgres · Self?=self-hostable · EU?=clean EU residency.

What OpenAlice's Rust stack should adopt — mapped to our known gaps

Our stack is axum + sqlx + per-service Postgres, self-hosted on Hetzner (EU). We don't replace it — none of the above is Rust-native and Postgres-native and self-hostable and batteries-included all at once. The play is to steal the right primitive from the right reference for each known gap. Ranked by leverage:

1. Durable job queue — adopt the Laravel Horizon + Convex durable-workflow shape, build on Postgres.

• Reference designs: Laravel Queues/Horizon (driver abstraction + retries/backoff + batches/chains + unique-locks + a visible dashboard with failed-job retry + worker autoscaling) and Convex's `@convex-dev/workflow` (journaled, restart-surviving, multi-step durable workflows). Supabase ships `pgmq` (Postgres-backed queue) which proves the "queue in Postgres" pattern works without new infra.
• Concrete: a pgmq-style table-backed queue in our existing per-service Postgres + a small Rust worker crate; ship the operability triad Horizon teaches (throughput/wait metrics, failed-job inspection+retry, tag-based grouping). Add journaled multi-step workflows (steps + state + retries) à la Convex for our agentic long-running flows. Highest leverage — it's the gap with the most mature references.

2. OTel tracing — we already have W3C trace-context propagation wired; we need the collector + auto-instrumentation, and Encore is the model.

• Reference: Encore's built-in automatic distributed tracing (instrument-once-trace-everywhere across services, with OTel export) is the gold standard here, and Laravel's `Context` is the ergonomic pattern for the hard part we'll hit: propagating trace context across the HTTP→queued-job boundary (dehydrate context into the job payload, rehydrate on the worker, auto-attach to every log line).
• Concrete: stand up an OTel collector (we already propagate W3C traceparent), wire tracing + tracing-opentelemetry spans on every axum handler and sqlx query, and — critically — serialize the active trace/span context onto every enqueued job (gap #1's queue) so background work joins the same trace. The Laravel Context dehydrating/hydrated model is the exact pattern to port to tracing task-locals.

3. Feature flags — adopt Laravel Pennant's tiny design (we already cross-referenced it).

• Reference: Pennant (define-resolver + persistent store + stable per-subject bucketing + rich/variant values + percentage rollout + bulk purge). Firebase Remote Config confirms the value (server-driven flags + A/B). No platform here beats Pennant's simplicity for self-host.
• Concrete: a define('flag', |subject| -> value) registry + a Postgres-backed feature_flag_values table for stable assignment + a percentage/lottery resolver helper. ~200 LOC of Rust; very high leverage for trunk-based dev and gated rollouts. Note the overlap we already flagged: Pennant/Queues/Context are the three Laravel batteries we're explicitly mining.

4. Hybrid search + reranker — nobody ships a turnkey reranker; build it on pgvector ourselves.

• Reference reality check: Supabase, Convex, Firebase all ship vector search but none ships a built-in reranker, and hybrid is "assemble it yourself" everywhere. Supabase's pattern (pgvector + Postgres FTS (`tsvector`) fused in SQL) is the most directly portable to our sqlx stack.
• Concrete: pgvector (HNSW) for dense + Postgres FTS for sparse, RRF/weighted fusion in SQL, then a separate Rust reranker step (cross-encoder call) — this is genuinely our own to build; the market gives us the retrieval half, not the rerank half. Treat the reranker as a first-class OpenAlice differentiator since the field is empty.

5. Typed codegen — adopt the Encore/Convex "types flow from the source of truth" ergonomic.

• Reference: Encore (typed Go/TS request/response → generated client SDKs) and Convex (_generated end-to-end types) set the bar; Supabase (gen types typescript from live schema) shows the DB-schema→types path.
• Concrete: generate typed clients from our sqlx/axum API definitions (OpenAPI-from-axum → TS client codegen, or a utoipa-style annotation pipeline). Since our DB is Postgres, the schema→types path (Supabase model) is also free leverage for internal tooling.

6. S3/CDN — adopt Laravel's Flysystem-style storage abstraction over an S3 backend; transforms/CDN bolt-on.

• Reference: Laravel Filesystem (Flysystem) is the cleanest abstraction (unified API across local/S3/SFTP + signed/temporary URLs); Supabase/Appwrite prove on-the-fly image transforms are expected table-stakes.
• Concrete: a thin Rust storage trait over an S3-compatible backend (MinIO on Hetzner or an EU S3) with signed/temporary URLs, front it with a CDN, and add an on-the-fly image-transform endpoint (resize/format) — Appwrite/Supabase show this is a baseline expectation, not a luxury.

7. Staging + blue-green — adopt Xata-style Postgres branching for environments; build a rolling cutover.

• Reference: Xata's copy-on-write Postgres branching (sub-second prod-like clones + PII anonymization on branch) is the standout for branch-per-PR / staging with realistic data — and it's vanilla Postgres, so it composes with sqlx. Supabase branching is the same idea at BaaS level. No platform here hands you turnkey blue-green; that stays ours (the dossier confirms even the managed platforms leave self-host cutover to you).
• Concrete: evaluate Xata-OSS (or simpler PG CREATE DATABASE ... TEMPLATE / logical-copy + anonymization) for ephemeral per-PR databases, and build a rolling/blue-green deploy (two binary slots + health-gated traffic switch) in our own deploy tooling — which is exactly the lane-state/binary-promotion discipline we already practice on prod.

Bottom line. The market validates our backlog rather than obsoleting it: every adjacent platform leaves at least three of our seven gaps unsolved, and the two hardest (turnkey reranker and managed blue-green for self-host) are unsolved everywhere. The efficient path is to port small, proven primitives — Pennant (flags), Horizon+Convex-workflows (durable queue), Encore tracing + Laravel Context (OTel across the job boundary), Flysystem (storage) — onto our Postgres/sqlx foundation, while treating reranking and blue-green as first-class OpenAlice-owned engineering rather than something to buy.

Authored by Tycho Brahe, 2026-06-21. Items flagged `[unverified-2026, from knowledge]` were not re-fetched under the research budget — confirm against current docs before any decision depends on them. Web research was deliberately bounded (~2–4 fetches/platform) per the efficiency directive after a prior run hung.