To ORM or Not to ORM?

I love having lunch with people smarter than me (which is often). I recently connected with Jeremiah Brazeau, a distinguished engineer and former leader at  Twilio and currently Shopify.

We talked stacks, and one comment struck me (paraphrasing): “Avoid using an ORM, I’ve been burned too many times.”

Let’s dig in.

ORMs (Object Relationship Managers) have been around for a long time; they are libraries that help coalesce relational databases to typed objects in an object-oriented programming language.

After doing this stuff for multiple decades, I am convinced that, in general, a relational database is the best tool for most storage jobs (PostgreSQL FTW) . I also love *thinking* in strongly-typed Objects.

I actually really like ORMs, and I have used many:

• Hibernate (Java)
• SWLALchemy (Python)
• ActiveRecord (Ruby/Rails)
• TypeORM, Prisma, Drizzle (Node)

Some ORMs are chock-full of features, and some are lean and mean.  ORMs’ features often include:

• Schema Management & Migrations
• Query Builders (with type safety)
  —-
• Connection Management / Abstraction
  —-
• Entity Managers
• Lifecycle Management
• Caching

I have a hard time imagining living without the first two. Having migrations in code to be reviewed at PR time is critical. And type-save query builders are a great way to keep your data access patterns DRY. The last three excited me at one time, but once projects and/or teams got to a certain scale, I found them to be a source of performance issues, unintended consequences, or side effects.

For Hi Marley Labs, I am going to try to use Supabase directly with their tooling without using a drizzle or prisma. I think that will achieve my goal of taking the best parts of what I need from ORMs.

I would also love to connect with folks who have used Supabase at scale and over multiple years.

For more insights and to share your thoughts, follow me on LinkedIn!