The problem with thinking a library like Mongoose satisfies those constraints is that it only works with a single application. Every database I've worked with that made it beyond a prototype outlived the original application. So you either end up building an RDBMS app/api in front of mongo for every new application to use or you have to translate those constraints to every client.

I'm of the opinion to let the "awesome, heavily-used, heavily-tested" RDBMSs built to manage data and constraints do just that.

True, using a library to hide the limitations of a DB smells bad. It is fixing the problem in the wrong location.

I may have misread your comment but rarely do more than one client application access a database. Especially in today's often Microservices architecture. So using a library as mentioned is fine. And as the app evolves/gets rewritten you can keep the library or replace it with a similar one.

Over 10+ years ago I did join a few projects with existing architecture that had evolved to multiple applications accessing the same database. And they were a nightmare but that is rare to encounter these days as most people have learned that one app = one DB. (Data warehousing is a possible exception, but mostly those datasets are exported instead as well as streams for machine learning).

Probably preaching to the choir but multiple clients mean feature freeze/deadlock, no DB refactoring and spaghetti architecture.

> rarely do more than one client application access a database

That has not been my experience!

This post isn’t about a single snapshot in time, this is about all of the people who didn’t evaluate MongoDB properly over the years and then were “burned” by it. I actually think it has received a bad rap due to people over the years not evaluating it properly. Sure, some of these things have changed (transactions very recently), but they all come with serious caveats and limitations that need to be explored... which was the main point of the article.

Hey Justin, thanks for writing the article! I agree with you that there was a failure of evaluation, and that MongoDB has matured quite a bit since the NoSQL explosion.

Sorry if my comment came across as a criticism of your post. It was more targeted at the long threads of people bashing MongoDB, thinking the caveats are still relevant/accurate today. Because they really aren't – MongoDB is a completely valid choice of database today.

ACID transactions were added over a year ago, and Mongoose is almost as old as MongoDB itself.

> > Having a database enforce these relationships can offload a lot of work from your application, and therefore from your engineers. > I've never seen anyone use MongoDB without also using something like Mongoose where you get all this for free. Zero work for your engineers.

For me, Mongoose is actually another argument against MongoDB. It's basically trying to add basic functionality on top of MongoDB, that most RDMS already have.

And no, it does actually not "all of that", just some of it. Just an example: Mongoose would still let you delete a user, while all of the related posts are remain with broken references to that user.

> Can you give an example of something that you realistically would want to do in SQL that you can't with a JSON query?

Sure everything can be done, it's just clunky and hard to get right. This graphic perfectly summarises the horror of writing simple queries in MongoDB: http://twiki.org/p/pub/Codev/TWikiPresentation2016x07x14Mong...

I've been using Mongoose in production for several years, 2011-2014 and again for the last 12 months, within teams of 4-8 developers. The amount of engineering, bug fixing and testing was definitely higher in MongoDB than with MySQL or Postgres.

Once I got to work with MySQL and Postgres after 2014, I found it so much easier to query for the data I'm looking for and to ensure data strong consistency, mind you, even without any use of a library!

Lack of ability to enforce structure - when using Mongo with C# you’re working with a strongly typed Collection<T> where types are enforced by the compiler when you add records and a strongly type IMongoQueryable<T> when you query the database.

Custom query language - I bet he also hates ElasticSearch. But again, using C# and the first party Mongo LINQ library, you are working with LINQ - the same built in C# query language that every C# developer should be familiar with. One of the requirements I wrote when I was hiring contractors for a Mongo based project was familiarity with Entity Framework. Even though we wouldn’t be using EF, if they knew it, it would be seamless to transition over to Mongo/LINQ.

Edit:

And as a side note, creating your “application defined schema” from a pre-existing JSON document, is a simple matter of copying the JSON to:

http://json2csharp.com/

This is fine and well if you're using your team's language tooling to enforce these things. But the moment you're outside those boundaries all bets are off.

Even if I’m using an RDMS, as a tech lead, I still enforce only one “service” writes to a particular set of domain related tables. I don’t mean an http microservice necessarily. It could very well be a separate project/module in a monolith or even a package/module shared via an internal package manager.

But I would never use a weakly typed language and a weakly typed data store. That’s a mess waiting to happen.

> Can you give an example of something that you realistically would want to do in SQL that you can't with a JSON query?

Can you define joins in terms of each other? Otherwise, any join that isn't left outer join ($lookup) can't be represented in an aggregate query AFAIK.

Most of this counterpoint seems to revolve around the third-party library Mongoose.

I'm not that deeply familiar with MongoDB first-hand. Is Mongoose something you can bring to bear as a plugin on the database server? Or is it strictly a client application library?

Because to analogize to relational databases:

* If you cite PL/SQL, T-SQL, PL/pgSQL, etc as solutions for SQL's shortcomings, then you have a point.

* But if you point to JPA/Hibernate, Entity Framework, SQLAlchemy, or just raw hand-rolled application-tier logic, then that's no counterpoint at all. Because it means that only one client can safely use the database, and that assumption breaks down in the real world beyond the toy proof-of-concept stage.

Mongo has supported schema enforcement for a few years now, it's not used often but if you want it, it's there.