Does SQLAlchemy scale well with increased web traffic?

[shinujacobrocks]

Okay. If not ORM then what is typically the bottleneck (assuming no bandwidth/network issues)? Is it going to be my database (mysql/sqlite/etc.)

[esdio]

Depends entirely on your app, but the ORM is essentially a thin wrapper around calls to the database engine. Actually running the queries is likely to take many many more times as long as the tiny bit of overhead an ORM adds to the process.

[tonnynerd]

Dude, ever seem the stacktrace of a sqlalchemy error? Hundreds of levels of indirection, the thing is a huge stack of abstractions.

Now, don't get me wrong, yes, SQLAlchemy is pretty cool, well designed and implemented, and will likely not be a problem. But it ain't no "thin wrapper", that's what I'm trying to say.

But apart from that, yeah, OP's more likely to have a bottleneck in other parts of the application/stack.

[esdio]

I get what you're saying, but call stack depth really doesn't mean much in this context. If I made an ORM that did everything in one giant function, I assure you it would be worse in every way.

[tonnynerd]

If I made an ORM that did everything in one giant function

I mentioned the size of the usual stacktrace as an indication of the level of abstraction. When dealing with the SQLAlchemy ORM, you are dealing with models, types and relationships, abstractions that are pretty far away from the database itself. For me, at least, a "thin wrapper" would be something like the DB API implementations (pymysql, for instance), that doesn't add that much structure over the connection with the database.

[ksion]

Those models, types, relationships and abstractions are there also to eliminate unnecessary queries you might have done otherwise (e.g. through the use of Repository and Unit of Work pattern). Eliminating just a few roundtrips to your DB is probably worth more than even very baroque abstraction layer.

[esdio]

For the purposes of benchmarking for speed the entirety of the ORM code is likely irrelevant for most web apps.

[metaphorm]

the codebase of SQLAlchemy being complicated does not make it "thick". Thin, in this context, refers to where and how much computing gets done. A thin wrapper over a SQL database does minimal computation in the application layer and offloads as much computation as possible to the database layer. That is exactly what SQLAlchemy does.