> ## Documentation Index > Fetch the complete documentation index at: https://docs.pylonsync.com/llms.txt > Use this file to discover all available pages before exploring further. # How Pylon compares > Honest comparisons against Convex, Supabase, Firebase, Colyseus, Playroom Kit, and Nakama. Every framework and backend is good at something. This section is the honest version of "should you use Pylon or X" — written so you can hand it to your tech-lead and they'll trust it. We don't sandbag competitors; we use primary docs where the comparison matters. ## App backends | | Pylon | Convex | Supabase | Firebase | | ---------------------- | -------------------------------------------------------------- | ------------------------------------------ | ----------------------------------------- | ----------------------------------------------- | | **Best for** | Real-time apps that also want Rust game shards, in one service | TypeScript-first reactive apps | Postgres apps with managed auth/storage | Mobile apps with managed everything | | One service / one port | ✅ | ❌ 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 | ⚠️ text/vector search, no native facets | ⚠️ Postgres `tsvector`, no native facets | ⚠️ Enterprise text search or third-party search | | Tick-based game shards | ✅ Rust `Shard` (client hook in TS) | ❌ | ❌ | ❌ | | Open source | ✅ MIT/Apache | ✅ FSL | ✅ Apache 2.0 | ❌ | | Pricing model | Self-host infra or Pylon Cloud plan + machine compute | Hosted usage + team seats; self-host infra | Hosted tiers or self-host infra | Hosted pay-as-you-go meters | Drill down: [Pylon vs. Convex](/compare/convex) · [Pylon vs. Supabase](/compare/supabase) · [Pylon vs. Firebase](/compare/firebase) ## Game servers One important qualifier before the comparison: Pylon's authoritative game shards are written in **Rust** — the `Shard` crate — with a `useShard` React hook to connect from the client. Unlike Pylon's app-data side (schema, policies, functions, sync are all TypeScript), there is **no TypeScript API for authoring a shard's server simulation** today. So these rows compare a Rust shard runtime against Node/Go/managed game servers; if your team won't write Rust, the shard column doesn't apply. | | 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-authoritative client model | ✅ | | Area-of-interest | ✅ built-in | ⚠️ StateView/per-client filtering | ❌ | ⚠️ 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 + external DB | | Open source | ✅ MIT/Apache | ✅ MIT | ❌ proprietary | ✅ Apache 2.0 | Drill down: [Pylon vs. Colyseus](/compare/colyseus) · [Pylon vs. Playroom Kit](/compare/playroom) · [Pylon vs. Nakama](/compare/nakama) ## How we keep these honest * **Primary sources for vendor-sensitive claims.** If a vendor ships a feature, we should describe it the way their current docs describe it. * **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.) * **Review when docs or pricing change.** If you spot a stale claim, [open an issue](https://github.com/pylonsync/pylon/issues). ## How Pylon fits in your stack Pylon is a **full-stack realtime framework**. You can use its server-rendered React surface, or pair the backend with whatever you're already shipping on the frontend — **Next.js, React + Vite, Expo / React Native, Swift / SwiftUI**. The dedicated SDKs ([`@pylonsync/next`](/clients/next), [`@pylonsync/react`](/clients/react), [`@pylonsync/react-native`](/clients/react-native), [Swift SDK](/clients/swift)) 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-high — port Schema classes to Pylon's `SimState`; the tick logic is rewritten in Rust, not reused from JS | | **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** by downloading a snapshot, restoring it with `pylon restore`, and running the same binary * **Self-host with the same binary** — no proprietary runtime, no vendor SDK that only talks to us Build with confidence that you can leave.