App backends
| Pylon | Convex | Supabase | Firebase | |
|---|---|---|---|---|
| Best for | Apps that need real-time + multiplayer in one process | TypeScript-first reactive apps | Postgres apps with managed auth/storage | Mobile apps with managed everything |
| Single process / binary | ✅ | ❌ docker-compose | ❌ multi-service | n/a (managed only) |
| Self-hostable | ✅ | ✅ | ✅ | ❌ |
| Realtime sync | ✅ | ✅ | ✅ | ✅ |
| TypeScript functions | ✅ in-repo | ✅ in-repo | ⚠️ Edge Functions (Deno, separate deploy) | ⚠️ Cloud Functions (separate deploy) |
| Faceted search | ✅ FTS5 + roaring bitmaps | ❌ FTS only | ⚠️ Postgres tsvector, no native facets | ❌ requires Algolia |
| Tick-based game shards | ✅ | ❌ | ❌ | ❌ |
| Open source | ✅ MIT/Apache | ✅ FSL | ✅ Apache 2.0 | ❌ |
| Pricing model | $0 self-host or per-use Cloud | Per-use only on Convex Cloud | Per-tier on Supabase Cloud | Per-use only on Firebase |
Game servers
| Pylon | Colyseus | Playroom Kit | Nakama | |
|---|---|---|---|---|
| Best for | Apps with real-time data + game shards in one stack | Standalone game server in Node | Quick web games with shared state | Production multiplayer with social features |
| Tick-based authority | ✅ | ✅ | ⚠️ host-relay model | ✅ |
| Area-of-interest | ✅ built-in | ⚠️ @filter decorators (manual) | ❌ | ⚠️ presence-based, manual |
| Matchmaker | ✅ | ✅ | ✅ | ✅ |
| Declarative app data | ✅ entities + policies | ❌ game state only | ❌ shared state only | ⚠️ Storage Engine (typed JSON) |
| Live queries for UI | ✅ | ❌ | ❌ | ❌ |
| Self-hosted as one binary | ✅ Rust | ⚠️ Node + your code | ❌ managed only | ✅ Go binary + Postgres |
| Open source | ✅ MIT/Apache | ✅ MIT | ❌ proprietary | ✅ Apache 2.0 |
How we keep these honest
- Linked sources for every claim. If we say “Supabase doesn’t have native faceted search”, the linked Supabase doc is the receipt.
- No scoreboard inflation. Where a competitor is genuinely better at something, we say so. (Supabase’s Postgres-native data layer is more flexible than ours for analytics; Convex’s pure-TS dev loop is genuinely tighter for greenfield TS apps.)
- Quarterly review. This page is checked against current vendor docs every quarter. If you spot a stale claim, open an issue.
How Pylon fits in your stack
Pylon is the backend. It’s designed to pair with whatever you’re already shipping on the frontend — Next.js, React + Vite, Expo / React Native, Swift / SwiftUI. The dedicated SDKs (@pylonsync/next, @pylonsync/react, @pylonsync/react-native, Swift SDK) exist precisely so you don’t have to choose between Pylon and your favorite frontend story. That’s the happy path, not a compromise.
When we’d recommend NOT using Pylon
There aren’t many cases. The honest ones:- You’re already deep in the GCP stack. Firebase + GCP integrate cleanly with Cloud Run, BigQuery, Pub/Sub, and the long tail of Google services. Pylon doesn’t.
- You need warehouse-scale analytics. Move analytical workloads to ClickHouse, DuckDB, or BigQuery. Pylon is for transactional realtime app state, not OLAP.
- You’re shipping pure RPC over HTTP with no realtime story. A simple Express/Fastify app or tRPC is lighter if you genuinely don’t need sync, policies, multiplayer, or any of the rest.
What about raw Postgres access?
Today Pylon’s entity API is the data API — no raw SQL escape hatch. That’s a deliberate constraint while we ship the cross-backend (SQLite + Postgres) story, not a permanent stance. When you’re on Postgres mode there’s no architectural reason to gate-keep CTEs, window functions, materialized views, or pgvector — and a raw-SQL escape hatch (e.g.ctx.pg.query(sql, params) available only in postgres-live builds) is on the roadmap. Until then, if a query genuinely doesn’t fit the entity model, you can run a Postgres extension or sidecar against the same database — Pylon doesn’t lock the DB.
Switching costs
If you’re already on a competitor and considering a move:| From | Migration difficulty |
|---|---|
| Convex | Medium — port defineSchema to Pylon’s schema DSL, port reactive queries to useQuery, port functions to mutation/action |
| Supabase | Medium-high — port SQL schema to Pylon’s manifest, port RLS to Pylon policies, replace Realtime subscriptions with useQuery |
| Firebase | High — denormalized Firestore data needs reshaping; auth migration is tractable via the magic-code flow |
| Colyseus | Medium — port Schema classes to Pylon’s SimState, keep your tick logic |
| Playroom Kit | Low — Playroom’s small surface area maps cleanly |
| Nakama | High — Lua/Go match handlers need rewriting in Rust |
Migrating from Pylon
We treat lock-in as a bug. Every Pylon deployment can:- Export to JSON or SQL via
pylon export/pylon backup - Migrate from Cloud to self-hosted in one command (
pylon backup --source cloud) - Self-host with the same binary — no proprietary runtime, no vendor SDK that only talks to us