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 possible to have all your data accessible in one process.  Users can spin up their own single process with access to all data, both live and historical.

Simpler architecture

There are some details to consider on reloading and mapping data on disk when it’s being appended to “live”, but on the whole you have fewer processes, and fewer process types. There’s no coordination problem between rdb and hdbs and gateways, so your system may well be simpler.

So let’s talk a little more about this…

Alternative default architecture

Standard kdb+ architecture is the way it is for a good reason.  If you’re in a world where memory is much more expensive, and all of your non-volatile storage is spinning disks, it makes a lot more sense to split your database in two.  Inserts against splayed tables on disk will be much slower than memory, likely several orders of magnitude, and any queries that do not hit the OS page cache (cold cache) will be drastically slower, again probably several orders of magnitude.  But this is no longer the world we live in.

I’m proposing an alternate default architecture that looks more like this: