Real numbers, not projections

We pushed BiseraDB to a real breaking point — on purpose.

Before trusting BiseraDB with our own production data, we ran it through a genuinely large, sustained load test: millions of records, tens of gigabytes, concurrent writes, and full-collection scans. Here's exactly what happened, with the real numbers.

Architecture

Memory bounded by design, not by luck.

The core promise we tested: BiseraDB's memory usage should scale with how much data is actively being worked with, not with how much data exists. A page-based storage engine with a bounded buffer cache backs every record on disk — the engine keeps hot data close and lets cold data stay on disk until it's needed, instead of holding an entire collection in RAM just because a client asked for a single record.

That's what let a ~20 GB dataset run comfortably in under 2 GB of memory throughout the test, and it's what makes an unindexed scan across a million-plus records return safely, in bounded batches, instead of pulling the whole collection into memory to answer one query.

Dogfooding

We found real issues under load — and shipped the fixes to ourselves first.

Sustained concurrent writes and large full-collection scans are exactly the conditions that expose real engineering gaps that smaller tests don't. Our load test did its job: it surfaced two genuine memory-bounding issues in the storage engine before they could ever reach a customer. Both were root-caused, fixed, and re-verified against the same worst-case load until the engine held steady.

We didn't stop at "it passed the test." The same day those fixes were verified, we deployed them to BiseraDB's own production instance and migrated our internal console platform's operational data onto it — the same engine now running this checkout, our internal admin tooling, and our migration platform, with zero data loss and every record verified field-for-field against the original source.