The only database that speaks the Cloud Bigtable protocol — without Google Cloud.
No HDFS. No ZooKeeper. No JVM.
Nearly 5,000 enterprises run Apache HBase — the open-source Bigtable implementation. It works, but operating it is painful:
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.
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.
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.
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. |
Because the adapter operates at the HBase Java API level, the entire HBase ecosystem can target RowKeyDB — including Apache Spark HBase connectors, OpenTSDB, Apache Hive storage handlers, and any Java application using the HBase client API.
Single-node persistent storage is complete. Multi-node clustering is next.
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
A server asked for more work than it can do has two ways to respond. It can accept everything and attempt all of it at once, growing slower and slower until it serves no one; or it can refuse the work it cannot finish and protect the work it has already taken on. The second response is the right one, and it is harder than it sounds, because the server must choose what to refuse before it has done enough work on any request to know what that request will cost.
Limen makes that choice. It is a small library, written in C++ and released as open source under the Apache 2.0 license, that watches how long the server takes to answer and adjusts on its own how much work the server will accept at one time. We built it to defend RowKeyDB against overload, and we release it freely because every server has the same problem to solve.
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.
One of the principal authors of the open-source Bigtable emulator at Unoperate/bigtable-emulator (Apache 2.0, copyright Google LLC) — contributing garbage collection, row atomicity and transactions, conditional mutations, ReadModifyWrite, and table sampling. RowKeyDB is the production-grade evolution of that work — adding persistent storage, crash safety, and multi-node clustering.