Compared to

voidbase compared to Supabase

Supabase and voidbase want the same thing: a backend you can own. They disagree about what owning it should cost you in operations.

	voidbase	Supabase
Database	SQLite through D1. No interactive transactions, 100 bound parameters per statement, 100 columns per table.	Postgres, with joins, extensions and thirty years of tooling.
Source	Open, MIT.	Open, Apache 2.0.
Self-host	One command into your Cloudflare account. It is the only mode.	Possible and documented. Postgres plus a handful of services, usually with Docker Compose.
What you operate	Nothing. There is no machine.	A database and the services around it, or you pay them to.
Rules enforced by	The server, on every request. The same guarantee in practice, a weaker one in principle.	Postgres itself, through row-level security.
Server logic	Hooks and endpoints in JavaScript, inside the instance.	Edge functions on Deno, plus Postgres functions and triggers.
Scaling	Per request, automatically. No instance size to choose.	A bigger instance, plus read replicas and connection pooling.
Where it runs	Every Cloudflare region.	The region you picked for the project.
Cost when idle	Nothing.	A hosted project bills for its instance whether or not anyone visits.
Realtime	One connection per client, fanned out by a durable object. No charge per message or per connection.	Postgres changes broadcast over websockets, which is more capable. Billed by peak concurrent connections and by message.
Seeing what it is doing	Cloudflare's logs and request data are there. Nothing is set up for you or shown in the panel.	Logs, query performance and reports in the dashboard.
Ecosystem	Young, and small. You may be the first to hit a given bug.	A company, support, and a large body of people who hit it before you.

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

What Supabase does better

Postgres, and it is not close. Joins, window functions, materialised views, full text search, PostGIS and pgvector, on a database people know how to operate. voidbase runs on SQLite through D1, with the limits in the table above. If your data needs Postgres, use Postgres.

Row-level security is enforced by the database, so a rule holds no matter which client wrote the query. voidbase enforces API rules in the server, which is the same thing in practice and a weaker claim in principle.

It is also a far bigger project, with a company behind it, a support contract if you want one, and a large body of people who have hit your problem already.

What voidbase does better

Self-hosting that is a command rather than a project. voidbase deploy creates the database, the bucket, the queue and the realtime object in your account and puts the server on top of them. No compose file, no Postgres to upgrade, no service to be paged about.

Cost at rest, which decides whether a side project survives. An idle voidbase instance bills for stored bytes and nothing else. A hosted Postgres bills for the instance.

Distance. Your code runs in whichever region the request arrives at, so someone in Sydney is not waiting on a database in Virginia.

Pick Supabase if

You need Postgres, or you want the rules enforced in the database, or your team is happy paying for a hosted product and would rather have the bigger ecosystem behind them.

Pick voidbase if

You want the open-source promise to be the thing you actually run, SQLite is enough for your data, and you would rather have no server than a well-managed one.

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 Supabase

$30.00/month

Pro

3.1× the voidbase bill

Pro baseone project, one instance: $25.00
Monthly active users100k, 100k included: $0.00
Database disk1.5 GB, 8 GB included: $0.00
File storage50 GB, 100 GB included: $0.00
Realtime connections1,000 peak, 500 included: $5.00
Realtime messages2M, 5M included: $0.00

In Supabase's favour: reads and writes are not billed per operation, so all the API traffic above costs nothing here. What it does cost is compute, and sustained load means a larger instance than the Pro base includes. That upgrade is not modelled, so a busy app's real bill is higher than this.

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 supabase.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 SupabaseAcross 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.

Supabase~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	Supabase
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	Postgres replication broadcast over websockets, billed by peak connection and by message
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

One region per project, with the database next to the code.

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.