Most platforms like ours run on cloud virtual machines. We chose to rent whole servers instead, as a rule from OVHcloud. This is why, and what we give up for it. Like the rest of what we write before launch, it describes how we are building KoedoDB, not a claim that it has been audited.
A database is only as steady as its CPU
On a shared virtual machine, the processor time you pay for can be taken by a neighbour you cannot see. The operating system reports it as “steal time”. When it is low you never notice; when a neighbour gets busy, your database answers slower for no reason you can find. For a database that is the worst kind of problem, because it comes and goes.
On a dedicated server there is no one else’s virtual machine on the same processor. The cores and the memory you are sold are the cores and the memory in the box. We still set limits per project, but the limits are ours, not a hosting provider’s.
Each project’s database in its own virtual machine
We run each project’s database in a small virtual machine of its own, so that a mistake or an attack in one project has to cross a hardware boundary to reach another. A virtual machine needs the processor’s virtualization support. On a rented virtual machine that means running one virtual machine inside another, which is slower and not something every provider offers. On a dedicated server it is simply there.
No surprises from someone else’s maintenance
A provider that runs thousands of virtual machines has to patch the machines under them, and sometimes it has to do it at once. In October 2026 we saw this on a test setup: some of our servers at a virtual-machine provider were powered off, one after another, for about twenty minutes, and the email explaining it arrived afterwards. The reason was a real emergency, so we do not blame them. But a customer’s database should not depend on it.
With a dedicated server, a reboot is something we decide and announce. The provider can still have hardware trouble, but not a hundred other customers’ emergencies on the same host.
What it costs us
Dedicated servers are not free of trouble, and we would rather say so:
- We run the machine. The operating system, the disks, the kernel updates, the firewall: they are ours to keep patched. There is no managed layer to lean on.
- Capacity comes in lumps. Ordering a server takes hours to days. We therefore order the next one before the current one is full, not after.
- One server is one thing that can fail. A virtual machine can be moved to other hardware by its provider. For a dedicated server we rely on backups and on being able to restore a project onto a new machine. We have not yet timed that restore on real hardware at launch scale, and until we have, we do not want you to take it for granted.
- Distance. Our servers are in the United States. From Japan the round trip is roughly 200 ms, so an app that makes many small queries in a row will feel it.
We think these are the right trade-offs for a service whose job is to keep your data and keep out your neighbours. If we find we are wrong about one of them, we will write about that too.