At Blazing we also build GPU db and have always loved what this project (Alenka) is doing. First of all when you are talking about I/O bound which I/O are you t

At Blazing we also build GPU db and have always loved what this project (Alenka) is doing. First of all when you are talking about I/O bound which I/O are you talking about? Do you mean from disk? From RAM? There are many ways of getting around some of these I/O bottleknecks like sending compressed data or processing while transferring. You're assumption that these workloads are typically I/O bound is correct but then agian GPU databases aren't always going after the most "typical" workloads. If you are doing large amounts of transformations, or complicated joins then you also can benifite hugely from the use of a gpu. Ever try to join several tables together across multiple columns? If you do then you should probably use a hash join and if you are using a hash join you better believe you are going to want to do be doing computationally intensive things like sorting and hash generation. Have you tried any gpu databases to see if this concern is valid? GPU dbs can take advantage of things like very expensive cascading compression that many normal databases can't.