Faraaz Ahmad

The "SQL doesn’t scale" argument is a lazy and absurd generalization. The real question isn't whether SQL or NoSQL scales; it’s whether a database meets your requirements or not. If a specific feature is critical to your usecase and only one database provides it, would you choose something else? Of course not. Every database both scales and doesn’t scale - it depends on the usecase you are building on top of it. If you are getting 100 req/sec, why bother with a sharded database? A single node instance is good enough. Scalability is just one factor in database selection, not the only one. Always consider the core properties, needs, and requirements you need for your use case and then choose an apt database, but be ready to live with the flaws and limitations that come with it. If someone tells you SQL doesn’t scale, ask them what they actually mean.

Anthropic had 16 AI agents build a C compiler from scratch. 100k lines, compiles the Linux kernel, $20k, 2 weeks. To put that in perspective GCC took thousands of engineers over 37 years to build. (Granted from 1987 - however) One researcher and 16 AI agents just built a compiler that passes 99% of GCC's own torture test suite, compiles FFmpeg, Redis, PostgreSQL, QEMU and runs Doom. They say they "(mostly) walked away." But that "mostly" is doing heavy lifting. No human wrote code but the researcher constantly redesigned tests, built CI pipelines when agents broke each other's work, and created workarounds when all 16 agents got stuck on the same bug. The human role didn't disappear. It shifted from writing code to engineering the environment that lets AI write code. I don’t know how you could make the point AI is hitting a wall.

Nah man. They want to hire this guy. I’m wheezing.

ORMs are an anti-pattern once you start operating at scale. At scale, most move away from them as the abstraction that bridges the database and programming language never fully holds. At scale, by using ORM, you almost always end up missing native database optimizations. And if you are already writing raw queries to work around ORM limitations, you are actually better off using prepared statements directly. The ORM abstraction hides query complexity, yes, but it does make it easy to ship inefficient N+1 queries without realizing it. Debugging becomes painful at the worst possible time - during production incidents. ORMs tend to lag behind database features. Indexing strategies, query hints, and newer capabilities are either inconvenient to use (just look at prefetch in Django ORM) or simply unavailable. This makes you opt for the lowest common capability (as offered by ORM) instead of leveraging the database properly. At scale, explicit queries are always simpler, faster, and easier to optimize; the cognitive overhead of mapping objects to tables is often not worth it. To be fair, ORMs make sense for prototypes and for getting to market quickly. Use them when you are starting out or in the early phases, but have a plan to migrate away from them :) Easier said than done, though; been there!