256GB is 256 billion bytes. So you can only fit over a hundred billion rows into 256GB if you have zero overhead and every row is smaller than roughly two bytes... ;) [so you couldn't even store a single proper integer in each row in your example]

Also, querying a static dataset that you can fit completely into RAM is not exactly "intractable to handle in real-time" without a GPU. You can do that just fine using the CPU right now.

Case in point: Even MySQL can handle 256gb of rows in memory with ease if you give it that much ram... Essentially, any single-machine database (gpu or not) can only process the same datasets that traditional single-machine databases (like MySQL) can already handle, albeit maybe a bit faster.

I think a good example for a "newsql" usecase that does _not_ fit into classical solutions like MySQL or Postgres would be web tracking (clickstream) data: Even a medium sized web property (say alexa top 100 in germany or france) will generate dozens of gigabytes of tracking data per hour. over the period of months, this adds up to hundreds of terrabytes of data. There is no way to load that much data in one piece into any of the classical databases.

EDIT: Maybe I should add a disclaimer: I'm the founder of another open-source database product that could be considered a competitor to MapD.