Motivation

Why a new database system?

The major open source general-purpose SQL databases as of 2025 are Postgres, SQLite, and MariaDB (formerly known as MySQL). They are all awe-inspiring projects with strong abilities in what they focus on. However, we feel like each one of them also has significant limitations, oddities, historical baggage, and architectural decisions that have become outdated.

Instead of criticizing in detail these projects, each of which we have high respect for, we'd rather simply ask, "Can we (the community) do better?" -- and if so, what would "better" look like. We'll only focus on comparison where we're looking to specifically do things differently, and hopefully can justify those decisions well enough to not incite a flame war.

We invite you to join us on this journey of hopefully building the next 40 years of databases.

How can I trust my data to be safe?

KantoDB is new, still in development, and has no significant adoption yet. As of 2025Q1, you should not trust your data to it.

We do not wish to make claims about durability and functionality without first having test coverage sufficient for the claims. We intend for the evidence to speak for itself. We aim to use formal methods as much as we can muster, and good testable design (sans I/O1, fuzzed, etc) for the rest.

Yes, we know we are crazy.

Version v0 will be primarily intended for bootstrapping the development, getting all the tooling in place, and for making major architectural decisions. This is where we worry about row formats, schema evolution, and such.

Version v1 will focus on being a viable production-ready Postgres/SQLite replacement, using RocksDB for data storage. RocksDB is an industry standard library for ordered key-value storage and provides us with production ready functionality needed in a SQL database engine.

Version v2 is far in the future, but will hopefully implement a novel disk storage format tuned for modern NVMe storage, written in pure Rust.

1

Sans I/O (popularized by https://sans-io.readthedocs.io/) refers to the idea of separating logic from input/output calls, and for KantoDB is mostly applicable with the from-scratch v2 storage format. (We could abstract out the whole RocksDB API, but it's quite large, complicated, and much more work than "read 2 MiB from disk at this offset".)

Is KantoDB Open Source?

Emphatically yes. Apache 2 licensed, about as permissive as it gets.

We have no intent of rug-pulling the community with a non-open-source license later, but naturally nobody trusts statements like that anymore.