4 ms·
> are there still good reasons for using it in a new project in 2025? I've written this before: if your data looks like trees, with some loose coupling between
by tgv 1y ago
> are there still good reasons for using it in a new project in 2025?
I've written this before: if your data looks like trees, with some loose coupling between them, it's a good choice. And most data does look like trees.
It does place some extra duties on the backend. E.g., mongodb doesn't propagate ("cascade") deletes (this also happens to be a feature I dislike: not so long ago, a delete of an insignificant record triggered an avalanche of deletes in a postgresql database, and restoring that took quite a bit of time.)
- Semaphor 1y agoCascading deletes are an optional feature in every DB that supports them, aren’t they? I only have DBA-ish experience with SQL Server, but there they are fully opt in.
- mxey 1y agoPostgres defaults to preventing delete when foreign keys would be violated, not cascading.
- tgv 1y agoThe sane default. It was a Django project, and unfortunately many relations were set to ondelete=cascade.
- nailer 1y ago> I've written this before: if your data looks like trees, with some loose coupling between them, it's a good choice. And most data does look like trees. I had an education statup a little while ago. Courses had many cohorts, cohorts had many sessions. It really was much nicer having a single tree structure for each course, appending new cohorts etc, rather than trying to represent this in a flat Postgres database. That said I acknowledge and agree with other commenter's experiences about MongoDB and data loss in the past.
- elcritch 1y agoMy main concern would be with querying. What is querying like in modern mongodb, or scylladb? I've seen couchbase ads showing a superset of sql, etc. Last I recall Mongo had a weird query system.
- senderista 1y agoBasically it requires you to write the query plan yourself, which IMO is not a bad idea for an OLTP system.