Discover more from Hacking SaaS
Hacking SaaS #17 - To ORM or Not to ORM
What Twitter has to say about ORMs, OLTP scalability updates and other news for SaaS Developers
Relational databases are generally wonderful, but they do have the pesky problem of following a relational model - which doesn’t always play well with the object-oriented model used by many languages. ORMs were designed to solve this problem, but they created some new problems. Are ORMs still popular? and if so, which ones?
Below, I explore this question with help from friends in the community. I also have some good links on scaling OLTP systems, a new SQL standard, and a new video on the SaaS Developer Youtube. So read on!
I was curious about which ORMs are most popular these days. So I asked the good people on Twitter which ORM they were using. I intentionally didn’t ask about specific languages - I was curious about different ORMs in all languages.
I got 87 responses to the survey on Twitter, plus a few more on Slack.
Out of these, 23 said they prefer not to use any ORM. Some were quite passionate about the lack of ORM in their lives.
Additional 23 gave a response along the lines of “I use X, which isn’t really an ORM, but…”. I counted all the various “Not an ORM but…” responses in the same way that I counted ORMs. So you will see a mix of all popular frameworks.
The Typescript ecosystem is dominated by Prisma (35% of Typescript responses). The “long tail” had ten different frameworks (!), which seems expected from the Typescript ecosystem.
Java ecosystem is led by Hibernate (47% of Java responses) and JooQ (33%).
Python is split nearly 50/50 between Django (56% of Python responses) and SQLAlchemy (43%).
Ruby is almost a monoculture, with 91% of the votes going to ActiveRecord and a single vote for Sequel Gem.
Figma blogged about their recently concluded database sharding project. Their blog has two sections:
Exploration: They review all the options they looked at and the constraints they faced. Eventually, landing on the decision to vertically shard their monolithic database. Vertical sharding means splitting it by internal use case and not by logical partitioning key (like tenant ID).
Migration: They go into a lot of detail on how they set up their architecture - routing, proxies, replication, and so on.
This is a great blog post for anyone interested in data architecture. I hope to have the Figma team on our Youtube / Podcast soon - so if you have questions about their decisions or migration that you want me to ask them - let me know, either on the SaaS Developer Slack or in the comments below.
If you are interested in the more theoretical side of DB scalability, I recommend this somewhat provocative CIDR23 paper: Is Scalable OLTP in the Cloud a Solved Problem? It is a very readable “big picture” paper that starts by comparing the four architectures for scalable OLTP (with real-world examples of each); it then advocates for one of the architectures, explores challenges with this architecture, and suggests promising directions for solving these challenges. Murat has a Tl; Dr version of the paper in his excellent blog.
Updates to SQL Standard
Peter Eisentraut shared breaking news on his blog - the latest revision to the SQL standard has been wrapped up by the working group and sent to ISO for official standardization.
I doubt this new revision will change anyone’s life. The previous revision was done in 2019, and I don’t quite remember it as a groundbreaking change. DBs seem to evolve in a way that seems rather decoupled from the standard.
Still, the new revision has both small-but-important nits (like officially supporting order-by and group-by together - something that works in almost every DB but is officially not allowed) and a large official standard for graph queries in SQL.
Postgres Logical Decoding Messages
Over on the SaaS Developer YouTube, Gunnar Morling shared a little-known Postgres feature that has some nice use-cases for stream processing. We discussed his InfoQ blog on the topic, The Wonders of Postgres Logical Replication, and as a bonus, he shared how this feature can help prevent a known problem in Postgres where the WAL doesn’t get deleted because one of the replication slots does not advance.