I think this may slightly improve the too-fine-granularity locking, and it might make full table scans a bit more efficient, but otherwise most of what I wrote in the post applies. In fact the metadata problem has gotten worse and you might have to move even more data around.

It would help if you could push down filter predicates to run locally inside Redis, but at that point you're already more than a key-value store. I wonder if you could do this using Lua?

Having Redis to the work is what http://thredis.org/ was about - and it was blazingly fast. I just couldn't find a use for it, so it's mostly collecting dust at the moment.

I think you could, but at this point you're butting up against the event loop assumption: that most of the work is IO. If you do compute on the edges, you then want threads, and you're re-engineering redis (Edit: I should have read grandparent's link, where he does just this).

But the core idea of pushing predicates to edges seems reasonable. At one point, I built this sql engine that coordinated queries and pushed down queries to the edges. It assumed that each edge store implemented an iterator over all its values, with optional filtering and sorting (if not implemented on the edge store, then the engine/client would filter/sort). It works great, but I haven't yet published it for other reasons.

Hey, amateur here - but has anybody tried to do a database where your edge servers literally run jit code? Like, you'd define a predicate like an OpenCL kernel, as a small ball of code taking a predetermined set of constants or per-row variables, then presumably push this as LLVM bytecode and let the edges compile it into locally appropriate loops (probably with caching). Is the problem there that it would become hard to apply optimizations that depend on awareness of data structure at a higher-than-row level?

So there are plenty of systems that compile portions of a SQL plan to bytecode (LLVM or JVM) or machine code directly. Usually, the part you compile is the SQL plan and most importantly the predicate filters.

Common operations like networking, transaction management and even index walks (except the key comparisons) are already compiled to native code, so you don't need to go all in. You just optimize the stuff that needs it.