0 Get started
Firebase is the default for a reason: an SDK on every platform, a database that syncs itself, and analytics and crash reporting in the same console. Pithy is a set of capabilities that compose into a Worker you deploy. The difference that decides it is not the feature list — it is whether your data plane is Google's or yours.
Choose Firebase
When time to first screen is the only thing that matters.
Native SDKs on every platform, offline-first sync that genuinely works, push notifications, Crashlytics, A/B testing and analytics — all wired together and all in one console. Nothing else in this category is as complete on mobile, and pretending otherwise would waste your time.
Choose Pithy
When you want to keep the account your customers' data sits in.
Every table, bucket and index is provisioned into your own Cloudflare account. There is no data plane we operate, no proprietary query language to unlearn, and the SQL you write is SQL. The trade is real work you would otherwise not do — and an exit that does not require a migration project.
Where they overlap
If a feature is standard for a modern backend, assume both have it. We are not going to dress one up as a differentiator.
Sign-in, OAuth providers, sessions and tokens. Both have it, and neither should call it a differentiator.
Upload, serve and authorize access to objects. Table stakes on both sides.
Your code, run on demand, without a server to keep alive.
Firebase has emulators; Pithy runs the whole stack on Miniflare. Both let you work offline.
Firebase has FCM; the kit has a durable email capability. Different shapes, same table stake.
Both can embed content and search it by meaning, and both lean on the platform underneath to do it.
The difference underneath
Firebase is a managed data plane. Firestore, Cloud Storage and Cloud Functions run on Google's infrastructure, and your application reaches them through SDKs that speak their protocols. That is what makes it fast to start, and it is also what makes leaving it a project rather than a decision.
Pithy provisions into your Cloudflare account. The D1 databases, the R2 buckets, the Vectorize indexes and the Workers are yours, named <project>-<env>-<thing>, visible in your own dashboard and billed on your own account. Nothing in the request path belongs to us, because there is nothing of ours in the request path.
The consequence worth stating plainly: with Firebase, the answer to "where do my customers' records live" is Google. With Pithy it is "in the database I provisioned", and that difference is the reason to accept the extra work.
Feature by feature
| Feature | Firebase | Pithy |
|---|---|---|
Runtime & data | ||
| Managed database included Firebase: Firestore and Realtime Database, both NoSQL; SQL Connect adds managed Postgres Pithy: D1, which is SQLite, provisioned into your account | Yes | Yes |
| Relational SQL Firebase: through SQL Connect, a separate managed Postgres service Pithy: D1 is the default and the only one; there is no second data model to choose between | Yes | Yes |
| Offline-first client sync Firebase: the thing it is genuinely best at Pithy: not offered, and not attempted | Yes | No |
| Realtime subscriptions Firebase: a core primitive of both databases Pithy: Durable Objects hold authoritative session state; there is no declarative table subscription | Yes | Partial |
| Durable multi-step workflows Firebase: Cloud Tasks and functions, assembled by you Pithy: Cloudflare Workflows, with capabilities that already use them | Partial | Yes |
| Pick your region Firebase: chosen at database creation and permanent — you cannot move it later Pithy: Cloudflare places data; D1 location hints and jurisdiction controls are the lever | Yes | Yes |
Identity | ||
| Sessions and OAuth Firebase: an extensive provider list Pithy: magic link, email OTP, Google and Apple | Yes | Yes |
| Passwordless by default Firebase: supported alongside passwords Pithy: the only option; there is no password database to leak | Partial | Yes |
| Mobile-first bearer tokens Pithy: a short-lived JWT verified locally against published JWKS | Yes | Yes |
| No per-active-user pricing Firebase: Authentication bills MAUs, and SMS separately Pithy: Cloudflare bills what your Worker runs | No | Yes |
Money | ||
| Payments in the platform Firebase: Extensions wrap Stripe; the cross-rail case is yours Pithy: Apple, Google, Stripe, Paddle and Lemon Squeezy on one entitlement | No | Yes |
| One entitlement across every rail Pithy: gating code names the key, never the SKU | No | Yes |
| Per-user balance ledger Pithy: atomic, idempotent and overdraft-safe by database constraint | No | Yes |
hyi187 | ||
| Authoritative sessions Pithy: a Durable Object holding state no client can be trusted with | No | Yes |
| Matchmaking Pithy: room codes, invites, a friend graph and a skill-bucketed queue | No | Yes |
| Skill rating Pithy: MMR per pool, which the open queue buckets on | No | Yes |
| Leaderboards with closing windows Pithy: daily through all-time, in SQL you can join against your own tables | No | Yes |
Trust & ownership | ||
| Your data stays in your account Firebase: Firestore and Cloud Storage are Google's data plane Pithy: every resource is provisioned into your Cloudflare account | No | Yes |
| Audit trail across the backend Firebase: Cloud Audit Logs cover the platform, not your app's actions Pithy: a queryable trail attributed to the actor, including the dashboard | Partial | Yes |
| Encrypted secret storage Firebase: Secret Manager, wired by you Pithy: a registry with two backends, per environment, with rotation | Partial | Yes |
| Humanity check as middleware Firebase: App Check, and it is good Pithy: Turnstile, stacked on any route's real strategy | Yes | Yes |
| Self-hostable Firebase: there is no Firebase you can run Pithy: the code is MIT and the account is yours; there is nothing to host of ours | No | Yes |
| No charges for egress Firebase: Firestore, Storage and Hosting all bill outbound data Pithy: R2 does not charge egress, which changes the arithmetic at scale | No | Yes |
Operations & DX | ||
| CLI scaffolding and migrations Firebase: the CLI deploys; schema is schemaless by design Pithy: one ordered migration registry per database, with tested rollbacks | Partial | Yes |
| Local emulation of the whole stack Firebase: the emulator suite Pithy: Miniflare, through `pithy dev` | Yes | Yes |
| A preview environment per branch Firebase: multiple projects, wired by you Pithy: `pithy feature` cuts a worktree, ports and its own ephemeral resources, and tears them down | Partial | Yes |
| Front end scaffolded into the backend Firebase: Hosting is a separate deploy Pithy: `pithy ui add react` — one origin, one build, one deploy | No | Yes |
| A polished platform console Firebase: a decade of it, and it shows Pithy: Cloudflare's own, and it is very good — the console the account already uses for Workers, D1, R2 and the logs | Yes | Yes |
| Panes for users, money and the trail Firebase: Auth users, Firestore documents, Crashlytics and analytics; entitlements and purchases are yours to model Pithy: users, entitlements, purchases, subscriptions, support and the trail — and a user can be comped, revoked or signed out everywhere | Partial | Yes |
| Crash reporting and analytics Firebase: Crashlytics and Google Analytics, integrated Pithy: not offered | Yes | No |
The saffron tick marks where Pithy leads — not that the other column is absent. Every claim about Firebase was checked against their own documentation on 2026-08-25; both products change, and this page is a snapshot rather than a maintained contract.
Where Pithy pulls ahead
Firestore and Cloud Storage are Google's infrastructure holding your customers' records. Every D1, R2 bucket and Vectorize index Pithy creates is provisioned into the Cloudflare account you already own, under a name you can read in your own dashboard. That is not a feature you use; it is a property you keep.
Apple, Google, Stripe, Paddle and Lemon Squeezy resolve to one cross-rail entitlement, with every purchase row in a database you own. Firebase has Extensions that wrap Stripe; the cross-platform entitlement case — buy on iOS, be entitled on the web — is entirely yours to build.
Authoritative turn-based sessions, matchmaking, skill rating, leaderboards and a ledger that cannot double-spend. On Firebase every one of those is something you write on top of Firestore, and the ledger is the one you will get wrong.
D1 is SQLite. Firestore is a document store with its own query semantics, its own indexing rules and its own limits on what a query may do. Neither is wrong, but only one of them is a skill you already have and can hire for.
Firestore, Cloud Storage and Hosting all charge for outbound data. R2 does not. For anything that serves files — media, downloads, user uploads — that single line is most of the difference in what the bill looks like at scale.
`pithy feature` cuts a worktree, reserves a port block, provisions ephemeral Cloudflare resources for that branch and tears the lot down afterwards. The Firebase equivalent is a second project you create and remember to delete.
Encrypted per-environment secret storage with rotation, and a queryable trail attributed to the actor — including when the vendor's own dashboard is the actor. On Firebase both are Google Cloud products you assemble yourself.
The code is MIT, the account is yours, and the exit is deleting our package from your `pithy.config.ts`. Leaving Firestore means exporting a document store into something else and rewriting every query that touched it.
Where Firebase wins
iOS, Android, Flutter, Unity and web, all maintained, all first-party. Pithy gives you an HTTP contract and documentation. On the first afternoon of a mobile project that gap is enormous.
A client that writes while disconnected and reconciles when it returns is genuinely hard, and Firestore does it well. The kit has no answer and does not pretend to.
FCM is the default path to a device on both platforms. The kit has durable email and nothing for push.
Crash reporting, funnels, A/B tests and Remote Config, all against the same user identity. That is a suite, not a feature.
Firebase's console is mature in the way only a long-lived product is. The Pithy dashboard is new and does less.
SQL Connect gives you a relational database without leaving the platform. D1 is SQLite, and SQLite is not Postgres.
An SLA, a status page and a support contract. With Pithy, Cloudflare is on call for the primitives and you are on call for your Worker.
Pre-built integrations for resizing images, syncing to BigQuery, wiring Stripe. Convenient, and there is no equivalent shelf here.
Cost
Both are pay-as-you-go rather than seat-priced, so this is not a plan-versus-plan comparison. What differs is the dimensions. Firebase bills stored data, operations, function time, monthly active users for Authentication, and network egress on Firestore, Storage and Hosting. Cloudflare bills requests, CPU time, rows read and written, and storage — and R2 does not charge egress at all.
| Firebase | Pithy | |
|---|---|---|
| Model | Pay-as-you-go on the Blaze plan | Pay-as-you-go on your own Cloudflare account |
| Identity | Billed per monthly active user | No per-user dimension |
| Database | Stored data, document operations, egress | Rows read and written, storage |
| Object storage | Stored data, operations, egress | Stored data, operations — no egress charge |
| Functions | Invocations, compute time, outbound networking | Requests and CPU time |
| Who bills you | Cloudflare, directly — there is no bill from us |
Both vendors set and change their own prices, and these dimensions were read on 2026-08-25. Firebase's pricing page and Cloudflare's Model your own shape before believing either of us.
It is a real conversion, and the database is the hard part. Firestore is a document store; D1 is SQLite. Collections become tables, denormalized documents become rows and joins, and every security rule becomes route-level authorization in your Worker. Nothing about that is mechanical.
The Firestore location decision is worth knowing before you start: it is set when the database is created and cannot be changed afterwards, so an export-and-reload is the only way to move data even within Firebase. If you were already facing that, the marginal cost of moving somewhere else is smaller than it looks.
What comes across easily is everything that was already yours: your client code's shape, your product logic, your assets. What does not is offline sync, push, and any query that leaned on Firestore's semantics.
If you are shipping a mobile app and want it working this week, Firebase is still the fastest path and this page is not going to argue with that. The case for the kit begins where the platform's convenience starts costing you something you mind — a data plane you do not own, a bill that grows with egress, an entitlement model you have to build anyway, and an exit that is a project rather than a decision.