Compared to

voidbase compared to Appwrite

Appwrite puts more in the box than voidbase does. voidbase asks less of the machine it runs on, because it does not have one.

	voidbase	Appwrite
Source	Open, MIT.	Open, BSD 3-clause.
Self-host	One command into your Cloudflare account.	Docker, running several containers together.
What you operate	Nothing.	The containers, their database, and the host they sit on.
Realtime	Durable object fanout. Connections are ordinary requests and messages are not billed.	Websocket channels, included in the plan and bounded by the host you run them on.
Server logic	JavaScript hooks and endpoints. One language.	Functions in many languages, each in its own container.
Isolation of that code	Hooks run inside the instance. Faster, less isolated.	Each function in its own container.
In the box	Auth, database, files, realtime, jobs, admin panel.	The same, plus messaging and more sign-in methods.
Runs anywhere	Cloudflare, or a local process. Not an air-gapped host.	Any Linux host with Docker, including one with no internet.
Where it runs	Every Cloudflare region.	Wherever you put the host, or their cloud.
Cost when idle	Nothing.	The host runs whether or not anyone visits.

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

What Appwrite does better

Breadth. Functions run in a long list of languages, not only JavaScript, so a team with Python or Go can bring it. Messaging, more sign-in methods and a larger console come as part of the product rather than something you wire up.

Isolation. Each function runs in its own container, so one of them looping does not affect the others. voidbase runs your hooks inside the instance, which is faster and less isolated.

And it does not care where it runs. Any Linux host with Docker will do, including one with no internet, which matters when the data is not allowed to leave the building.

What voidbase does better

Setup, by a wide margin. A voidbase instance is one command and no host. Appwrite self-hosted is a set of containers, a database to back up, and a machine to keep patched.

Cost shape. A container host bills by the hour. A Worker bills per request, so a project nobody is using costs nothing.

Compatibility with something else. voidbase speaks PocketBase's API, so the client libraries, the admin panel and the documentation already exist and are not ours. Appwrite's API is Appwrite's.

Pick Appwrite if

You need functions in a language other than JavaScript, or you want the extra services in one place, or the deployment has to be a machine you can point at.

Pick voidbase if

You want the same category of product with nothing to operate, and JavaScript hooks are enough server logic for what you are building.

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 Appwrite Cloud

$28.00/month

Pro

2.9× the voidbase bill

Pro baseone member, $10 of database credit: $25.00
Monthly active users100k, 200k included: $0.00
Reads20.0M: $12.00
Writes1.0M: $1.00
Storage50 GB, 150 GB included: $0.00
Bandwidth170 GB including realtime pushes, 2 TB included: $0.00
Database creditincluded every month: -$10.00

Realtime connections are included in the plan rather than billed per connection, so only what they push shows up, as bandwidth. The $10 of monthly database credit is subtracted and the bill floors at the $25 base. Reads and writes are charged from the first one rather than after an allowance, which is what makes this column move quickly.

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 appwrite.io/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 Appwrite CloudAcross 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.

Appwrite Cloud~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	Appwrite Cloud
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	Websocket channels, included in the plan and bounded by the host
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

Their cloud, or a host you run yourself, in one place either way.

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.