> A traditional database is somewhat tied to a disk for persistence, particularly if it is transactional, but this is more of a top fuel dragster with a mile to run.
Sure, for writing that's somewhat true (in many traditional RDBMs you can relax guarantees e.g. with UNLOGGED tables in postgres). But for reads, not really. Most databases have a buffer layer in front of the disk / os.
> Something like Postgres would be stuck on a single core at this point mostly waiting on memory bandwidth (with associated NUMA bandwidth issues of picking 1 core).
Obviously depends on the type of query (filtering, aggregation, joins ...) you're doing, but postgres can actually parallelize things to multiple cores these days (since 9.6, a lot more to be released with v10).
Unfortunately, if you're forced to use a single core, memory bandwidth is seldomly the actual bottleneck. In many cases postgres will be CPU bound elsewhere ("tuple deforming", evaluating filters / aggregation expressions), or for other types of queries memory latency will be much more important due to random access nature (think of hash-joins/aggs or nested-loop joins). We're working on that.
> Being able to use the memory bandwidth of the GPUs
That only really helps you if a significant portion of the working set fits onto GPUs. Which'll usually not if we're talking 60-100GB of main memory resident data. If you're reading sequentially through all that data you'll be bound by the main memory latency (including those NUMA issues etc you mentioned).
60-100GB? Many of our users run with 8 GPUs and 192GB VRAM, with larger VRAM buffers likely coming soon. And that's before you consider the fact that you don't need to cache all columns and partitions in a column store or compress the data. Its pretty easy to query 15+ active columns on 5B rows on a single server, and then there's scale out if you need more.
Sure, for writing that's somewhat true (in many traditional RDBMs you can relax guarantees e.g. with UNLOGGED tables in postgres). But for reads, not really. Most databases have a buffer layer in front of the disk / os.
> Something like Postgres would be stuck on a single core at this point mostly waiting on memory bandwidth (with associated NUMA bandwidth issues of picking 1 core).
Obviously depends on the type of query (filtering, aggregation, joins ...) you're doing, but postgres can actually parallelize things to multiple cores these days (since 9.6, a lot more to be released with v10).
Unfortunately, if you're forced to use a single core, memory bandwidth is seldomly the actual bottleneck. In many cases postgres will be CPU bound elsewhere ("tuple deforming", evaluating filters / aggregation expressions), or for other types of queries memory latency will be much more important due to random access nature (think of hash-joins/aggs or nested-loop joins). We're working on that.
> Being able to use the memory bandwidth of the GPUs
That only really helps you if a significant portion of the working set fits onto GPUs. Which'll usually not if we're talking 60-100GB of main memory resident data. If you're reading sequentially through all that data you'll be bound by the main memory latency (including those NUMA issues etc you mentioned).