Skip to main content
These comparisons spell out where Pylon and each alternative fit. Vendor-sensitive claims use primary documentation, and the tables call out features competitors handle better.

​
App backends

Drill down: Pylon vs. Convex · Pylon vs. Supabase · Pylon vs. Firebase

​
Game servers

Pylon’s authoritative game shards are written in Rust with the Shard<S: SimState> crate; clients connect through the useShard React hook. Schema, policies, functions, and sync use TypeScript, but shard simulations do not have a TypeScript authoring API. The shard comparison therefore applies only to teams willing to write Rust. Drill down: Pylon vs. Colyseus · Pylon vs. Playroom Kit · Pylon vs. Nakama

​
Comparison policy

  • 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 better, we say so. Supabase’s Postgres-native data layer is more flexible for analytics, and Convex has a tighter pure-TypeScript loop for new projects.
  • Review when docs or pricing change. If you spot a stale claim, open an issue.

​
How Pylon fits in your stack

Pylon is a full-stack realtime framework. Use its server-rendered React surface or pair the backend with Next.js, React and Vite, Expo or React Native, or Swift and SwiftUI. Dedicated SDKs cover each of those clients: @pylonsync/next, @pylonsync/react, @pylonsync/react-native, and the Swift SDK.

​
When Pylon is a poor fit

  • You are already deep in the GCP stack. Firebase and GCP integrate cleanly with Cloud Run, BigQuery, Pub/Sub, and many other Google services. Pylon does not integrate with these directly.
  • You need warehouse-scale analytics. Move analytical workloads to ClickHouse, DuckDB, or BigQuery. Pylon is for transactional realtime app state, not OLAP.
  • You are shipping pure RPC over HTTP with no realtime requirement. A simple Express/Fastify app or tRPC is lighter if you genuinely do not need sync, policies, multiplayer, or any of the rest.

​
What about raw Postgres access?

Pylon’s entity API is currently the only in-process data API. Raw SQL for Postgres builds, such as ctx.pg.query(sql, params), is on the roadmap. Until it lands, queries that need CTEs, window functions, materialized views, or pgvector can run through a Postgres extension or sidecar against the same database.

​
Switching costs

If you are already on a competitor and considering a move:

​
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