July 31, 2026 • By Brian Marete
Building RowKeyDB with formal methods and Deterministic Simulation Testing (DST) continues to be quite the fascinating odyssey for me.
DST is a methodology I am using to test that the code implementing the Raft protocol and its six necessary extensions behaves as expected under a wide variety of physical system faults—the kind that happen almost every minute in production.
The space of faults—network partitions (symmetric and asymmetric), delayed packets, CPU starvation events, disk slowness events, clock skew, and their respective frequencies—that can be simulated and tested is exceptionally large. Consequently, managing this state space is not a trivial problem.
June 28, 2026 • By Brian Marete
The C++ implementation of gRPC, otherwise an excellent library, has led me to petty chicanery and sin.
The Go and Java implementations of gRPC have natural, well-documented interfaces for the cheap (before any allocations, before any deserialization of protobuf payloads) interception of every request.
gRPC-Go has the Tap interface, specifically for this kind of thing.
gRPC-Java has the ServerTransportFilter interface for this kind of thing.
But for some reason that I cannot quite figure out, in the gRPC C++ implementation, what would at first glance pass for the natural interface for cheap circuit breaking—the grpc::experimental::Interceptor interface—is not only experimental and deprecated, but it is also not cheap. By the time a request gets there, the payload has already been deserialized, a lot of allocation has already taken place, and in general, a lot of computation has taken place.
June 28, 2026 • By Brian Marete
Girding my loins for the big push of adding multi-node mode to RowKeyDB, I spent last night adding an MSan (MemorySanitizer) CI workflow.
I had been putting MSan off mainly because I dreaded the headache—libstdc++ is infamously essentially un-instrumentable for the purpose, and so I had to swap that out for libc++, like everyone else does, for the MSan build.
In the end, it was not as painful as I expected, and the process was actually fruitful: Speaking a little roughly, libc++ and libstdc++ represent std::chrono::system_clock differently, and the libc++ introduction caused an overflow in clock arithmetic that was not there under libstdc++. Just the same, under MSan, this overflow was caught by a pre-existing unit test, which was fairly satisfying. This and an actual use of an uninitialized variable in observability test code (a real MSan find) were the only obstacles to a clean MSan build and test run.
June 26, 2026 • By Brian Marete
I am happy to report that RowKeyDB passes the entire integration and conformance test suite published for the Google HBase -> Cloud Bigtable adapter (which can be found here: https://github.com/googleapis/java-bigtable-hbase).
The single node RowKeyDB beta binary passed the test suite without modification for BOTH the persistent and memory backends, on the first try.
You do not have to take my word for it. You can download the binary I published a few days ago and test it yourself using these instructions on the release page: https://github.com/rowkeydb-com/rowkeydb-releases#hbase-compatibility-and-conformance-testing
June 25, 2026 • By Brian Marete
When designing RowKeyDB, we knew that a high-performance, Bigtable-compatible API shouldn’t just be restricted to durable storage. Many modern infrastructure challenges require the rich semantics of wide-column stores, but strictly for volatile, low-latency data.
That is why RowKeyDB ships with a native, memory-only backend. Simply pass --storage_backend=memory at startup, and your instance is ready.
It is common for databases to offer an in-memory mode that acts merely as a development crutch. We took a different path. The RowKeyDB memory backend is subjected to the same rigorous correctness tests as our durable engine. It supports the exact same Bigtable API. If your application works against the memory backend, it will work against the durable backend—and vice versa.