7 ms·
Decent list but the ORM thing makes me suspicious. He links here as some kind of damning proof that ORMs are default bad. https://openai.com/index/scaling-pos
by pragmatic 1mo ago
Decent list but the ORM thing makes me suspicious.
He links here as some kind of damning proof that ORMs are default bad.
https://openai.com/index/scaling-postgresql/ https://openai.com/index/scaling-postgresql/
“It’s a poor craftsmen who blames their tools.”
My ORM rule of thumb:
ORM for CRUD not Reports
If you are joining 12 tables for operational data, you have a design flaw. That’s a reporting query pattern.
Often temp tables, CTEs etc are needed as an immediate fix with redesign as a long term fix. The query planner simply can’t optimize that in a reasonable time or it’s beyond there scope if what it can optimize. Also their solution to “joining in memory” is common.
My DB query rule of thumb:
If the query is hard for you to understand, it’s hard for the planner to understand.
Default to small fast simple queries and pipeline them together.
- AdamN 1mo agoMy rule: ORMs first, if there are performance problems it's probably the db structure so don't be afraid of reworking the underlying database. In some cases though SQL gets you the specific thing you need so don't be afraid to use it occasionally in the code (fully parameterized of course and using as much of the ORM as possible for getting things like the table name rather than hardcoding).
- Shorel 1mo agoYour DB query rule goes against my experience. Sometimes longer and more complex queries run much, much faster. The users complain about "complexity", but when they see the performance comparison they change their minds.