Before we proceed, are you aware that a lot of popular database drivers for Ruby (and Python? not sure) implement the performance-critical bits in good old nati

Before we proceed, are you aware that a lot of popular database drivers for Ruby (and Python? not sure) implement the performance-critical bits in good old natively compiled C? For example, the Ruby postgres gem: https://github.com/ged/ruby-pg/tree/master/ext https://github.com/ged/ruby-pg/tree/master/ext (I wasn't sure until I checked just now, so I'm not questioning your familiarity with the tech. Just not sure if that's commonly known) So no, it's not the database, it's your interpreted language. Or it's your developers. If you're moving enough data over the wire that application-side serialization/deserialization becomes an issue, often this is because developers are retrieving a whole truckload of records when they really only ought to be returning one. Even in a fast application language, this is a problem. You're still burning extra CPU cycles, you're still allocating extra RAM, you're moving the same amount of extra data "over the wire", and you're still consuming extra database resources. Of course, there truly are many use cases where you might want to move a truckload of data between your application and your database, and do some heavy crunching on the application side. I wholeheartedly agree Ruby is not ideal for that.