Your Data. Your Rules. Your Database.
When tuning existing databases is no longer enough, we design a purpose-built engine for your workload and hardware. We agree what to measure before building. Our public orderbook engine shows how we approach the work.
This is the answer when tuning has run out of room. It is not the default answer.
A general-purpose engine carries overhead you never asked for: layers for workloads you do not run and features you will never call. Take those out and response time is measured in microseconds, because there is almost nothing left in the path.
Data structures built for one access pattern mean less compute, less storage and less network traffic for the same result. The saving shows up as hardware you no longer rack, and it is in the benchmark before you commit to anything.
The schema, the index strategy and the wire protocol all follow your data model and the machine it runs on. Nothing in the engine is there because some other client needed it.
A database engine for Level 2 order book data, written in C++20 for one workload on specific hardware. It is on GitHub: clone it, read how the storage layer is laid out, run the test suite, measure it on your own machine. This is what a crafted engine looks like when it is finished, and it is the same process your project would follow.
Results depend on hardware and workload. The public comparison documents its methods and limitations; it is not a performance guarantee for your application.
Read the engine source (opens in a new tab)Read benchmark methods and results(opens in a new tab)
Our engine's name is a claim about cost, so we measure cost: the server CPU each system spends loading the same 2,000,000 order book levels.
| Database | Order book levels ingested per server CPU-second |
|---|---|
| Orderbook DB Engine | 4.88 to 5.00 million |
| ClickHouse 26.9 | 1.64 to 2.25 million |
| TimescaleDB 2.30 | 0.63 million |
2.1 times ClickHouse's figure and 7.7 times TimescaleDB's, our slowest run against each one's fastest: fewer CPU-seconds for the same data means fewer servers and less energy.
Amazon EC2 m8a.xlarge (4 vCPU, AMD EPYC 9R45), 7 October 2026, five runs, with ClickHouse and TimescaleDB on PostgreSQL 16 installed natively. ClickHouse finishes the load first by using 2.4 to 3.0 cores where our engine uses 0.1; this compares what the load costs.
Two recordings of Binance order books, ten trading pairs over the same ten minutes, loaded into each system and measured on disk after its own compression.
| Database | Diff stream, bytes per row | Top 20 snapshots, bytes per row |
|---|---|---|
| Orderbook DB Engine | 3.78 | 0.53 |
| ClickHouse 26.9 as installed | 7.04 | 1.17 |
| ClickHouse 26.9, best of five codec sets | 4.31 | 0.87 |
| TimescaleDB 2.30, compressed | 17.29 | 12.45 |
What takes a terabyte in ClickHouse as installed takes 0.46 to 0.54 terabytes in our engine, and 0.61 to 0.88 of what ClickHouse needs with the best codec set we found for each recording. A replica joining a cluster and a backup copy the segments as they are on disk, so they move these bytes too.
Amazon EC2 m8a.xlarge, 7 October 2026: each recording loaded, flushed and left 90 seconds before measuring. The best codec set is the smallest of the five we tried for each recording.
Six situations where tuning stops helping. If a Smart Data Engine placement ended with "nothing off the shelf fits", it was one of these.
Your queries are too slow. You've tuned indexes, added caching, scaled up hardware, but you're still hitting walls that generic databases can't break through.
Your infrastructure bill keeps climbing. You're paying for features you don't use and overhead that doesn't serve your workload.
What worked at 1 million records doesn't work at 1 billion. Your database wasn't designed for the scale you've reached.
You've tried PostgreSQL, MongoDB, Redis, ClickHouse. Each solves part of the problem but none handles your specific data model perfectly.
You're running on specialized infrastructure: custom SSDs, FPGAs, or specific CPU architectures that off-the-shelf databases can't fully utilize.
Your data infrastructure is a differentiator. Faster queries, lower costs, and better performance give you an edge your competitors can't match.
Four stages, and you get a number to hold us to at the end of the second one.
We study your data with you: structure, volumes, access patterns, latency targets and the hardware it has to run on. If a crafted engine is the wrong answer, this is the stage where you hear it.
Data structures, index strategy and wire protocol, all chosen for your access patterns. The stage ends with a written benchmark: what better means, in numbers, on your data.
Implemented and measured against that benchmark continuously rather than at the end. Nothing reaches your production until the numbers are met.
The engine, the benchmarks, the test suite and the documentation. Your team takes it from there, or we run it as a managed service and you keep checking us against the benchmark.
Tell us what you tried, what it cost and where it stopped. If a crafted engine is not the answer, that is a shorter conversation and a cheaper one for you.
Start Your Project
