Who needs a real-time database?

Summary

The in-memory process has a more clear-cut advantage here. But it’s perhaps not as large as you might expect. It’s certainly much smaller than when your storage was slow spinning disks. And another crucial point here: inserts into memory are a serial process. When an rdb is inserting new data it cannot serve queries simultaneously. This is not true in the later case, we can insert to a splayed table on disk and at the same time processes can serve queries on the data. Compute and memory are separated. Why not have an rdb? Faster queries I know above I showed that the rdb is (ever so slightly) faster, but that’s for one query. What if you have 2, or 10? On an rdb you’re stuck running queries serially. It cannot run queries concurrently. However if your data is shared on disk (and in memory via the OS page cache) you can go parallel. Each individual query might take slightly longer, but you can run all 10 at once on separate processes. A query that is 10% slower on an hdb, becomes 45% faster if you need to run it twice as you can go parallel e.g. two queries at 110ms each running in parallel taking 110ms total vs two queries at 100ms serially taking 200ms. This is also a big architectural advantage if you want to support different types of use-case on the same system. For example research queries, and more latency sensitive trading queries, without them getting in each others way. All memory is shared by default We can shard and scale basically for free. rdbs have a fixed memory cost, if we want more processes we need more memory, and new processes are slow to startup as they need to read all current data into memory. When your data is only stored once, on disk and in the OS page cache, you can have 10 processes on top of it, or why not 100? These processes can startup almost instantly. This fundamentally separates memory and compute No gateways You can of course still have gateway processes if you want, but you don’t need them to join rdb and hdb data together. It’s ...