Hacker News Reader

Comment by parham | Hacker News Reader

My thought too but if your data is complex you should consider building an API first using an ORM more powerful than Django's (e.g. SQLAlchemy) then use Django to handle users and then allow your users to access the API directly via signed requests or something... that way you get good performance without network/Django ORM overhead.

View on HN

I prefer SQLAlchemy, but it definitely has just as much overhead as django's ORM. This is just a microbenchmark, but notice how when frameworks are making raw DB queries they stomp the ones using ORM:

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

Looking at only python frameworks using ORM, Flask with SQLA hits 85% of the requests/sec of Django using pypy, and only 73% on stock python. Django has decently lower latency as well (450ms django, 550ms flask pypy, 600ms flask stock python):

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

Really, if performance matters at all and you want an ORM use Java. The fastest python solution using an ORM is a tenth as fast as the Java solutions, with literally 10x the latency. :P Flask making raw db queries gets within 2x of this, as does bottle.

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

These numbers are somewhat misleading, and the phrasing may confuse people.

> The fastest python solution using an ORM is a tenth as fast as the Java solutions

This may be true if your bottleneck is the ORM in the first place (this is relatively easily verifiable by running a profiler on your python program, comparing the results against (e.g.) EXPLAIN ANALYZE output, etc.)

I run a service with a decently-sized database (over 100G); so far all the bottlenecks were at the "query execution in the DB" level. I use lower-level SQLAlchemy primitives to form the queries, and check the resulting raw SQL against the raw SQL queries that I had designed for the DB before. If you know what you're doing, SQLAlchemy will know, too.

Use cases and situations vary. But the way you phrase those particular benchmarking results is somewhat misleading.

I wasn't refering to performance, but the queries you could do. If performance was an issue and the ORM was the bottle neck then I would use raw SQL and scrap the ORM altogether. Thanks for this benchmarks though good to know that info! :)

Edit: The overhead thing was a secondary point my main point was handling data.

Reply on news.ycombinator.com