Hacker News new | ask | show | jobs
by ChicagoDave 28 days ago
ORMs taught me that relational databases are an operational anti-pattern.

NoSQL for operational data storage is more efficient and cost effective.

ORMs were a regression test that exposed unnecessary complexity.

1 comments

I’ve never seen any reliable service built on a NoSQL store as a primary data store. If data consistency and not losing customer data important for you, RDBMS are just fine.
Data consistency was solved in Mongo and DynamoDB years ago. CQRS is a better pattern. Read Models out of analytics (relational) data stores are better for dashboards. I stopped being "SQL First" ten years ago and never looked back. Saved clients time, money, and improved maintenance and eased feature additions.
It's sort of about your skills, if you are better at NoSQL then use that. But it doesn't mean that your experience is universal.

Relational databases are incredibly flexible even if you have a NoSQL mindset, you can do data modelling like that in Postgres too with jsonb data types.

Yes and for crud systems relational is fine because you're unlikely to over-complicated your architecture. But when a system starts talking to other systems and its bounded contexts become complex, alternate solutions should be sought.

The problem with "schema change", and I did this for decades, is that it's always a massive blocker. In some companies the data architects had to approve and implement schema changes. You could wait days for that. NoSQL allows you to modify the document surface in mostly non-breaking change ways OR it's easier to version your APIs to handle different document versions.

Simple CRUD: Any data store is fine. Complex multiple bounded contexts: Choose the appropriate data store for each bounded context accordingly.

My point was no one should be reaching for a relational database or starting with an ERD to build a system. Document behaviors. Model the system. Let the system decide what data storage it requires.

> Document behaviors. Model the system. Let the system decide what data storage it requires.

Counterpoint: force the system to use an RDBMS to store data in properly normalized schema, because it’s the only thing guaranteeing that the data will continue to exist as you expect.

This implies nosql data stores are not ACID capable. Mongo is fully capable and DynamoDB is mostly capable.

I would challenge you to look at event driven architectures, CQRS, event sourcing, and how to implement and leverage read models.

It will expand your architecture toolkit.

Much like I can’t take Prisma seriously because they shipped an ORM that couldn’t do JOINs, I can’t take any database seriously that can’t manage ACID. “bUt wE haVe BAsE.” Cool story. Relational databases are some of the oldest and best-tested pieces of software that exist. I trust them more than anything else - if you write it, it is persisted, full stop.
They are also the most expensive operational data stores and the younglings know almost no SQL or set theory.

Schema management is the single worst part of deployments.

If I build on DynamoDB vs RDS I can save 10x.