[codeslinger]

Just as I mentioned in today's thread on FathomDB, I'd be interested in what kind of workload scales linearly to 50 cores. I'm guessing its not very join heavy. H-Store's main advance, IIRC, was that it pushed many points of RDBMS engine operation into RAM. While this would indeed make the engine much faster and eliminate some historical cruft, I don't remember any fundamental breakthrough that would make distributed joins scale out very well. Anyone have any insights on how they are handling joins?

[codeslinger]

Some interesting points from the whitepaper regarding the above:

"VoltDB provides data access via stored procedures in order to minimize round trips between the client and the server. Stored procedures are written in Java - each procedure is a single Java class. Within the stored procedure definition, users interact with a VoltDB database via an OLTP-focused subset of standard SQL, including many-way joins, group-bys, ordering, aggregates, common arithmetic expressions, limits, etc."

"Distributed execution planner assigns work to engines, which operate exclusively on their assigned partitions"

I'm assuming this means they've reduced join functionality in order to get a much better scale-out profile. I wonder what this means for people writing apps on top of it.

[wmf]

I would describe H-Store as a key-value store that can perform occasional joins. The fact that so many Web 2.0ers are using join-less NoSQL databases shows that such workloads probably aren't join-heavy.