>Since from his charts it looks like the bulk of his processing time is due to the database connection and transfer, what other framework/language is going to eliminate that. I am sure many alternatives have faster routing, serialization, and response generation, but that doesn't seem to matter with a database involved.

Oh, it really does. Not all database drivers, not the rest of the pipeline from DB to your data object, are the same.

Take a look here: http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...

and here: http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...

Particularly interesting is how PHP, from being quite low as raw speed is concerned, gets way higher when multiple DB queries are used (due to the heavily optimized MySQL, 3rd generation IIRC, drivers I'd assume).

His measurement is around this line:

    users = list(User.objects.all())

That will include Postgres' work, the Python Postgres driver's work, and the ORM's work. Elsewhere, we've already seen that Postgres and MySQL can provide a response to such a trivial query over Ethernet in less than 5ms, under heavy concurrent load, on commodity hardware. But his measurement is 90ms.

For the sake of argument, let's say that hardware variations mean his local Postgres instance (that is, an instance without Ethernet latency to contend with) requires 20ms to fulfill the query. Maybe his laptop is from 2006. That still leaves 70ms unaccounted for.

It's not Postgres' fault.

In the article it's actually 9ms rather than 90ms--0.009 seconds.

Oh! Thanks for pointing that out. That means the numbers are more in line with what I've seen elsewhere. Sorry for the tangent!