Compared to

voidbase compared to Firebase

Firebase invented this category and is still the fastest way to get a mobile app talking to a database. The difference that matters is whose account the database is in.

	voidbase	Firebase
Who owns the account	You. It deploys into your own Cloudflare account.	Google. Your project lives in theirs.
Source	Open, MIT.	Closed. The client SDKs are open, the backend is not.
Self-host	It is the only mode. There is no hosted product to depend on.	No. The emulator is for local development, not production.
Database	SQLite through D1. A schema, relations, and SQL underneath.	Documents, no joins, no SQL. Simpler until you need a join.
Realtime	Subscribe to a collection over one connection. Pushes are not billed per message.	Mature listeners, wired into the offline cache. Every document a listener receives is billed as a read, so fan-out multiplies the bill by subscriber count.
Offline on the device	Nothing built in today. A service worker that queues writes is the next piece.	Writes queue on the device and reconcile. A decade of work behind it.
Client platforms	Good JavaScript and Dart clients. Others are community built.	iOS, Android, Unity, Flutter and C++, maintained by Google.
The rest of the box	A backend. No crash reporting, push or analytics.	Crashlytics, messaging, analytics and remote config, wired together.
Cost when idle	Nothing. Workers bill per request and CPU time.	Free tier, then per read, write and delete.
Reading data out	Free. R2 has no egress charge.	Billed as egress.
Getting out	Export the database as SQLite and the files as files.	Export works. Every query has to be rewritten.

in your favour not yet, and on the roadmap against you depends what you are building

What Firebase does better

Offline. The Firebase SDKs cache writes on the device and reconcile them when the network comes back, and that has been working for a decade. If your app has to keep functioning on a train, Firebase has already solved a problem voidbase has not.

The rest of the box, too. Crash reporting, push notifications, analytics and remote config are all there and all wired together. voidbase is a backend. It is not going to send you a crash report.

And the client libraries reach further, across iOS, Android, Unity, Flutter and C++, maintained by Google. voidbase speaks PocketBase's API, which has good JavaScript and Dart clients and community ones elsewhere.

What voidbase does better

The account. Your instance is a Worker in your Cloudflare account, with your database and your bucket next to it. Nobody can change the terms of a product you are not a customer of.

The data model. Collections have a schema, fields have types, relations expand in one request, and the filter language compiles to SQL. Firestore makes you shape data around the queries it can answer and denormalise the rest.

The bill at rest. A Firestore project with no traffic still holds documents. A voidbase instance with no traffic runs nothing and costs nothing beyond storage.

Pick Firebase if

Your app is mobile first and needs real offline behaviour, or you want analytics and messaging in the same place as the data, or your team already knows the console and would rather spend the time on the product.

Pick voidbase if

You want the data in an account you control, or you want SQL and a real schema, or you have been surprised by a bill and would like the next one to come from a provider whose pricing page you can read.

What it costs

Move the sliders to your own traffic. Both columns are computed from published list prices, and every assumption behind them is in the panel at the bottom of this section.

Reads / month20MWrites / month1MStored files50 GBPeak realtime connections1kMonthly active users100k

voidbase, on your own Cloudflare account

$9.79/month

Workers Paid, D1, R2, Durable Objects

Workers Paid basethe account minimum: $5.00
Requests21.0M, 10M included: $3.30
CPU time3ms a request: $0.66
Database rows80M read, 3.0M written: $0.00
Database storage1.5 GB, 5 GB included: $0.00
File storage50 GB in R2, egress free: $0.75
Realtime fanout1.5M durable object requests: $0.08

No per-user charge: signing in is an ordinary request, so monthly active users do not appear at all. Durable object compute is left out, because a hibernating connection bills none.

The same app on Firebase

not priced on this page

Firestore's per-operation rates live on a Google Cloud pricing page that would not load in full when this was built, and putting a competitor's prices on a public page from memory is not a thing worth doing. The free tier is documented and generous, 50,000 reads and 20,000 writes a day. The paid rates are the ones that decide a comparison, and they will appear here when they can be quoted from the source rather than recalled.

Model assumptions and sources

An estimate whose assumptions are hidden is an advertisement. This one assumes each API read or write is one Worker request; a read touches about 4 SQLite rows with a relation expanded and a write about 3; a request costs about 3ms of CPU, measured on this site's own instance; each realtime connection receives about 50 pushed updates a day; and a response is about 8KB where a plan bills bandwidth. A WebSocket connection is billed as one request and the messages over it are not, and a hibernating connection bills no compute. Monthly active users are an authentication headcount: voidbase has no per-user charge at all, because signing in is an ordinary request.

Rates as of 8 September 2026, from Workers, D1, R2, Durable Objects and firebase.google.com/pricing. Both columns are estimates. Measure before you commit either way, and tell us if a number here is wrong.

And what about speed?

Everything below this line is guesswork. We have not benchmarked these systems against each other, and we are not qualified to do it well. Doing it properly means controlled hardware, representative workloads, warm and cold paths measured separately, percentiles rather than averages, and somebody who has done it before checking the method. None of that happened here.

What follows is arithmetic over round numbers we believe are roughly right. It is here to give a rough shape of the trade to someone who wants one, and to annoy someone who knows better into correcting us. The numbers being multiplied are listed underneath so you can argue with a specific one. Do not choose a backend on this section.

How far the user is from FirebaseAcross an oceanDatabase round trips a request makes2Requests a second, at the busy moment100Clients subscribed at once1kAfter a quiet period, coldno

voidbase on Cloudflare~69 ms

Reaching the edge: ~15 ms
Database: ~50 ms
The handler: ~4 ms

The code runs near the user, so distance barely enters. The database is the slow part, because a Worker reaches D1 over the network rather than a socket on the same box.

A change reaches every subscriber in: ~8 ms
As the load grows: Flat. Capacity is added per request, so the number above does not change between ten requests a second and ten thousand.
What gives way first: Nothing here scales by being bigger. Requests spread across every location, and each instance's sockets are held by one durable object, so the first real limit is that object's own throughput rather than a machine size.

Firebase~130 ms

Reaching the region: ~120 ms
Database: ~6 ms
The handler: ~4 ms

The database is right there, which is the advantage. What it pays is distance: everyone far from that region pays the full round trip, and a page that makes several calls pays it several times.

A change reaches every subscriber in: ~8 ms
As the load grows: Flat until the instance is about half full, then it climbs the way a queue climbs: slowly, and then all at once.
What gives way first: One instance holds the sockets and serves the requests. Past about 800 requests a second or 20k subscribers, the answer is a bigger instance, read replicas, or both, and somebody has to notice and do it.

What we think the trade is

	voidbase	Firebase
Where the code runs	Every Cloudflare location, so near the user by construction	The one region you chose
Where the database is	A network hop from the code, which is the slow part above	Beside the code, so queries are quick
A user far away	Pays about the same as one nearby	Pays the full round trip, on every call the page makes
Cold start	Milliseconds: an isolate, not a container	Hundreds of milliseconds if it scaled to zero
Ten times the traffic	Same latency, more instances. Nothing to do	A bigger instance, and somebody to notice
A hundred times the traffic	Same again. The limit is your database, not the runtime	Read replicas, connection pooling, sharding
Realtime transport	One hibernating socket per client, held by a durable object	Listeners wired into the offline cache, with every delivered document billed as a read
Realtime fanout	~8 ms to 1k subscribers	~8 ms to the same
Subscribers before it hurts	Per instance, and the object hibernates when quiet	Bounded by the instance, and usually billed as well
Idle	Costs nothing and runs nothing	The instance runs anyway
What gives way first	Database throughput, or one instance's own durable object	The instance, and then the database behind it

Google's, with multi-region options for Firestore.

The numbers being multiplied

Correct one of these and the bars move. Reaching a Cloudflare edge location, 15ms. A Worker starting cold, 5ms, because an isolate is not a container. A container waking, 900ms. One D1 query from a Worker, 25ms. One query to a database beside the code, 3ms. One query to SQLite on the same disk, 1ms. The handler itself, 4ms.

The one we are least sure of is the D1 number, and it is the one that decides whether the first bar beats the second. It is also the one most likely to change: putting an instance's data in a durable object beside its own code would replace that network hop with a local read.

Please prove us wrong

If you benchmark backends for a living, we would rather publish your method and your results than our arithmetic. Open an issue on the repository with what you would measure and how, and we will run it, publish whatever it says, and replace this section with it.