The database doesn't need to be an issue - it just currently is. We have a fairly complex query on a several terabyte large PostgreSQL database and didn't want to spend more money. Basically, we just haven't sharded it yet, and don't want to pay for a larger machine. The point is - typically the issue isn't the web app. Almost all web frameworks are designed to be scalable from the start. Just launch another instance.

Also, we do about 99 writes for every 1 read, so query times don't matter as much. For the given app I was using as an example.

Network I/O and large databases are usually the bottlenecks from what I've seen consulting and developing.

This was probably true 10 years ago, but these days it's basically FUD. Since then Ruby improved performance something like 5-80x from 1.8 to 2.5 and moved from an interpreted language to a VM nearly as fast as LuaJIT. Go only has 3-5x the throughput for tasks like: grab 100 rows from PostgreSQL, serialize to JSON, respond via HTTP. Lots of the hot code in Ruby around fetching rows from the DB, serializing to JSON, and HTTP parsing have also since been implemented as native functions in C, massively improving performance with zero effort required by the developer.

yeah this is cool, until you make a single map...

Do you mean: "take a few thousand rows and map them to a different data structure"? Because I benchmarked that recently and mapping 16,000 rows of GPS points using haversine distance in pure Ruby takes about 12ms, and about 5ms in Go. It's not that much slower. There are tasks where Ruby can be ~100x slower than Go, but a simple map isn't one of them.

MySQL and PostgreSQL are considered “old” now? I’d guess that’s much like Rails being considered “old” and “legacy.”