| Reference | Customer | Contract | Device | Breaches | Penalty |
|---|
Everything above is served by one process. Not one
cluster, not one docker-compose file — one oxidb-server, about 14 MB
on disk, holding four different kinds of data at once and answering four
different wire protocols to do it.
A cold-chain compliance system, in miniature. Trucks carry vaccines and frozen food; probes inside them report temperature; the load has a contracted range it must never leave. That is the easy half. The hard half arrives two years later, when an auditor asks you to prove shipment SHP-1004 stayed in range for its entire journey — and to prove the record you are showing them has not been edited since.
The domain was not chosen because it is exciting. It was chosen because it is the rare application that genuinely needs all of this: a firehose of numeric readings, heterogeneous device events, live state, relational contracts and money, and immutable paperwork. Most demos have to invent a reason to switch on half their features. This one has to be talked out of using more.
Not that OxiDB can do these things — a feature list would say that more cheaply. The argument is that this is an ordinary .NET application. The code above uses EF Core, MQTTnet, StackExchange.Redis and the AWS SDK: four libraries that have never heard of OxiDB and are not configured to know. They are pointed at localhost ports and they behave exactly as they would against the systems they were written for.
Which means the interesting number is not a benchmark. It is the count of things you did not deploy. This dashboard would ordinarily sit on top of Mosquitto for MQTT, InfluxDB for the readings, Redis for live state, PostgreSQL for shipments and penalties, MongoDB for raw events, and MinIO for certificates. Six systems to install, secure, monitor, back up, upgrade on six schedules, and keep consistent with each other. Here they are five ports on one binary — and the backup is one archive, taken at one instant, with one restore.
A probe publishes a JSON payload to sensors/TR-06-XYZ/probe-04/temperature.
The ingest service is subscribed to sensors/+/+/temperature — one
wildcard for the truck, one for the probe — and from that single message it
fans out to four stores, each getting the shape of the data it is good at:
Every one had to pass a single test: would you reach for this if OxiDB didn't bundle it? Anything that fails that test makes the showcase weaker, not stronger — nobody is impressed that vector search was squeezed in; they are only impressed when it was already the right answer.
The document engine is the one that had to earn it hardest,
and the fleet is what earns it. Three vendors, no two agreeing: an old probe
reports a temperature and nothing else, a newer one adds humidity, a door switch
and a nested GPS fix, and a third calls its fields sensor_id and
temp_c and carries an alarm list. No fixed schema fits all three.
And the extra fields are not decoration — look at probe-04 above: the chart shows
its temperature climbing out of the band, which tells you that it
breached. The raw events show door_open: true, which tells you
why. The time-series engine can never hold that, and a schema designed
today cannot anticipate it. Keeping the event exactly as sent is the only honest
answer, and it is that engine's entire job.
The SQL engine earns it in the table above. Look at the penalty column: the same single breach costs 2,500 for the pharma customer and 400 for the grocer. Nothing about that is a document lookup — it is a join, from an excursion to a shipment to a customer to the contract they signed. That is what relational databases are for, and EF Core is how .NET teams already write it.
OxiMem earns it twice: once as the live view, and once invisibly — a failing probe reports a breach every second, and the flag that stops it writing a database row every second lives there, with a one-minute expiry. State that should evaporate belongs somewhere that forgets. It is also why a silent probe fades out on this page instead of showing its last temperature: absent is unknown, not fine.
Deliberately absent: vector search and WASM. Both would have been possible and neither would have been honest — "find similar excursion patterns" is a sentence nobody in this industry has said. Leaving them out is the same discipline that let the other six in.
A showcase is worth writing because it puts weight on things a test suite never does. Two real gaps turned up while this one was being built:
aws-cli
and boto3 never notice, and the .NET SDK throws on the way
home. Everything else here talks to OxiDB with zero accommodation; that one
needs a flag.Both are written down rather than papered over, because a demo that only demonstrates the parts that already worked is marketing, not evidence.
There are no transactions spanning two engines — each commits on its own. Nothing here is sharded; that is a separate axis, and this data would not need it until the fleet was very large. And the compliance story has one more chapter still unwritten on this page: the engine supports point-in-time recovery, an audit log, WORM storage and encryption at rest, which is the actual answer to the auditor's question, and which no ordinary demo ever has a reason to switch on.
OxiDB is under active development and is not yet recommended for production use. This is a demonstration, not a reference deployment.