Single node only

KantoDB is not a distributed database. It does not use Raft or Paxos or such distributed consensus mechanisms, it does not coordinate writes across a multiple server machines, and it does not "scale out". We intend to focus on easy disaster recovery over scale-out or high availability. This limitation keeps the software much simpler.

We do not care about scaling OLTP beyond a 448-core 24 TiB RAM server with a dozen 2 TiB NVMe drives (2025 numbers). That is a huge amount of data and processing ability most companies will never grow beyond.

We aim to compete with Postgres and SQLite¹, not with CockroachDB, Spanner, or such.

We care deeply about running as a library (like SQLite) with relatively low resource requirements. Think cheap cloud VM not embedded hardware, for now. This will also be core part of our developer experience, allowing you to run application tests against the library even when production is using a standalone server.

We care about easy, automatic and streaming backups to cloud object storage, such as S3 -- and disaster recovery from it.

We intend to support easy-to-run read-only asynchronous replicas, if that comes naturally.

We intend to support easy OLAP integration by exposing archived tables directly from object storage, as Delta Lake or such, when reads can lag and throughput is king. This may even be our chosen backup format.