Hacker News new | ask | show | jobs
by jd3 1218 days ago
I've seen this opinion on HN for years, but still don't _really_ understand it. Our cofounder built what is now a $1B+ SaSS company from some cursory SQL knowledge he gained while interning at a hospital in the early 2010's. The entire business is, in essence, a fancy graphical UI around postgres.

I've now been writing django at work for five years and still have yet to come across a query builder/orm which is as powerful yet simple in addition to being a breeze to on-board new engineers with.

When there are queries that require the use of non-django builtins, it's also relatively easy to use django raw sql or just straight up use the psycopg2 sql.SQL dynamic string composition helpers.

With the complexity of some our chained django QueryMethods, the company would have quite literally been impossible to build without django's query builder, at the very least.

1 comments

This is a double-edged sword in my opinion. The Django ORM is among my favourite ORMs, but the abstraction (like any) can cause problems over time.

At scale, poorly understood ORM-generated queries can be a real pain, especially if your team's SQL skills have atrophied due to over-reliance on the ORM.

As an exercise, I'd possibly recommend reviewing your top 1-3 worst performing queries, tracking them back to the ORM, and evaluating how to improve them.

> At scale

People often overestimate how often the average website needs to worry about scale.

And how easy it is to fix the times you come close.

I completely agree, except for the last line. It is in my experience very hard to post-hoc get people to care about query performance. Organizationally and technically. In a complicated monolith at scale, de-tangling the ORM is a multi-years long project.

Edited to say: as for the average website, I do completely agree. For the unique website that will scale as well, I likely would still 95/100 recommend the ORM, but my experience has taught me that there be some pain on the road.

Instagram uses Django, so I think it is possible to make anything work.