Why I Built DewDB Without TiKV

A lot of distributed databases rely on a separate distributed storage layer underneath them.

I wanted something simpler.

With DewDB, the database nodes themselves handle storage, replication, leader election, failover, sharding, and data movement.

There is no TiKV underneath and no separate coordinator.

A replicated DewDB group has a leader and replicas. If the leader dies, a replica can take over.

For scale-out, DewDB adds sharding. Each shard group has its own leader and replicas, so different shards can handle writes independently.

Why not just use TiKV?

Because then DewDB would become a document and query layer on top of another distributed database.

I wanted the thing you deploy to also be the thing doing the replication, failover, and sharding.

That means DewDB also has to own the difficult parts itself: elections, quorum logic, WAL recovery, replica repair, shard ownership, and migration.

That tradeoff is the whole point of the project.

DewDB is still young, but today it already has documents, queries, secondary indexes, replication, failover, sharding, change streams, and online shard migration.

If you want to try it on Windows:

iwr https://windows.dewdb.com -useb | iex

Then:

dewdb init
dewdb

GitHub: https://github.com/dewdb/dewdb