Compared to

voidbase compared to Encore

These are not the same kind of thing, which is the most useful thing to say about them. Encore is a framework for building a backend. voidbase is a backend. If you know which of those sentences describes what you want, you have your answer.

	voidbase	Encore
Day one	A running backend: collections, API, auth, files, admin panel.	A framework and an empty project. You write the services.
Infrastructure	Created on the first deploy: database, bucket, queue, realtime object.	Declared in your code and provisioned for you.
Where it deploys	Cloudflare, and only Cloudflare.	Their cloud, or your own AWS or GCP account.
Languages	JavaScript hooks.	Go and TypeScript.
Several services together	One instance. No typed calls between services, no tracing across them.	Typed calls, tracing, and generated API documentation.
Realtime to a browser	Built in: subscribe to a collection over one connection.	Not a feature. Pub/sub is between your services; pushing to a browser is yours to build.
Admin panel for content	PocketBase's panel, for editing data.	A development dashboard. Not for content.
Non-developers	Can edit content in the panel.	Everything is code.
Changing the schema	In the panel, live, or as a migration file.	A code change and a deploy.
Best at	Apps whose backend is mostly data with rules around it.	Systems with real business logic, and several services of it.

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

What Encore does better

Everything about writing a lot of server code. Typed calls between services, tracing across them, generated API documentation, a local development dashboard, and infrastructure declared next to the code that uses it. If you are building a system rather than an app, that is the right set of tools and voidbase does not have them.

It also meets you where your cloud already is. If the company is on AWS with an existing account structure, Encore provisions into it. voidbase requires Cloudflare.

And Go, if you want Go. voidbase's hooks are JavaScript.

What voidbase does better

Not writing the backend. Most applications need users, a few kinds of record, permissions, file uploads and a way for someone non-technical to fix a typo. voidbase has all of that before you start, and Encore expects you to build it.

Time to a first working thing, which is minutes rather than days.

And the admin panel, which is not a developer tool. It is the thing you hand to the person who edits the content, and a framework has no equivalent.

Pick Encore if

The interesting part of your system is the logic, you have more than one service, and you want typed calls and tracing between them.

Pick voidbase if

The interesting part is the product, the backend is mostly data with rules around it, and you would rather not write the same user table again.

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

$164.20/month

Pro

16.8× the voidbase bill

Pro baseone member: $49.00
Environmentone production environment: $99.00
Resources6 at $2.50: services, database, bucket, cron, queue, secrets: $15.00
Tracing events21M, 20M included: $1.20

There is no realtime line because there is no realtime product: pushing to a browser is something you would build and run on your own infrastructure. This is Encore's platform fee only. The infrastructure runs in your own AWS or GCP account and that cloud bills you directly for compute, storage and data transfer, which is not modelled here and is usually the larger half. The voidbase column, by contrast, is the whole bill.

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 encore.dev/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 Encore 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.

Encore 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	Encore 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	None to a browser. Pub/sub is between services; this is yours to build
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

Your own AWS or GCP region, so the same single-region trade.

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.