I think this is all well and good, especially the compatibility with Flask. However, the biggest issue is the data access layer. Most flask apps will use an ORM like SQLAlchemy(SA) to create their data access layer.

SA unfortunately, does not have a asynchronous version (its quite complex as it is). Therefore, I think it would require quite a lot of work, in order to actually get a standard flask app to work with quart.

However, if you've built your data access layer directly on psycopg, then I think you're good to go.

theptip

An interesting deep dive on why this is the case (from 2015), in case anyone wants to know more:

http://techspot.zzzeek.org/2015/02/15/asynchronous-python-an...

tomchristie

One thing I've never been able to reconcile is Mike Bayer's article there, set against Yury Selivanov's reported results for `asyncpg`, which at least as they're presented do indicate a significant difference in throughput.

https://github.com/MagicStack/asyncpg

They're both incredibly experienced developers, and I don't have any good steer on the discrepancy.

Would love to see some independent benchmarking on a typical use case to get a clearer picture on how valuable (or not) asyncio is for high-throughput database operations.