RowKeyDB — Production-Grade Bigtable Replacement

The Problem

Nearly 5,000 enterprises run Apache HBase — the open-source Bigtable implementation. It works, but operating it is painful:

Requires HDFS (Hadoop's distributed filesystem) — the #1 source of HBase outages
Requires ZooKeeper for coordination — another cluster to manage and monitor
Java runtime with stop-the-world garbage-collection pauses — unpredictable latency under load
Crash recovery takes minutes — distributed WAL replay across HDFS
Version upgrades are slow and risky — Pinterest was 5 years behind upstream because upgrades were "slow and painful"
Shrinking talent pool — HBase expertise is increasingly scarce as engineers move to modern systems

Google's managed Cloud Bigtable solves these problems — but locks you into Google Cloud. Neither AWS nor Azure offers a Bigtable API-compliant alternative. Enterprises not on Google Cloud have no modernization path that doesn't require rewriting application code.

The Solution

RowKeyDB is a Bigtable API-compliant key-value store written in C++. It runs on any cloud or bare metal with local SSD storage. Applications built for Cloud Bigtable work with RowKeyDB without code changes.

No HDFS — each node stores data on its own SSD with built-in crash recovery
No ZooKeeper — embedded Raft consensus for coordination
No JVM — C++ with deterministic memory management, zero GC pauses
Crash recovery in seconds — local WAL replay, not distributed
Fanatical data safety — acknowledged writes are never lost, verified by crash recovery tests that kill the process mid-write and confirm zero data loss on restart
Runs anywhere — GCP, AWS, Azure, or bare metal

Where HDFS replication goes: RowKeyDB is designed for enterprise-grade replicated cloud SSDs: GCP pd-ssd (99.999% durability), AWS io2 Block Express (99.999% durability), and Azure Premium SSD. These disks replicate every byte across multiple fault domains within the availability zone — the same durability guarantee HDFS provides, without the operational burden of managing a distributed filesystem. For multi-node deployments, RowKeyDB adds Raft-based replication across nodes for full redundancy.

Migration Paths

RowKeyDB speaks the Bigtable gRPC protocol. Different source systems have different migration paths:

Source	Migration effort	How
Cloud Bigtable	Zero code changes	Point existing Bigtable client libraries at RowKeyDB instead of Cloud Bigtable. Same protocol, same API.
HBase (Java)	Dependency swap	Google's open-source bigtable-hbase adapter (Apache 2.0) translates HBase API calls into Bigtable gRPC. Add one dependency, set one config property, no application code changes.
HBase (native API)	Client library change	Switch to Bigtable gRPC client libraries. Same data model — weeks of engineering, not the months required for a rewrite to a different database.

What's Built

Single-node persistent storage is complete. Multi-node clustering is next.

39.5K

Lines of C++

800+

Tests

Test suites

25 yrs

Founder experience

Full Bigtable API: all mutation types, 19 filter types, cell versioning, garbage collection rules, and authorized views. Crash-safe persistent storage with per-row concurrent access. Every mutation path is tested under memory sanitizers, thread sanitizers, and crash recovery scenarios. Data safety is not an afterthought — it is the first design constraint.

Single-Node Complete · Multi-Node In Progress

The Founder

Brian G. Marete — 25 years of software engineering, including 7+ years as a Site Reliability Engineer at Google (Googlebot, Google Lens, Bandwidth Enforcer). Staff and Senior Staff engineer. Deep expertise in building reliable, high-performance distributed systems where data loss is not acceptable.