Why not just use a SQL db that handles json and stick everything in a couple columns? Changing databases is a lot of work, and as far as I can tell, mongo isn’t really providing much value over SQL dbs that already support schemaless json columns.

"Support" for schemaless json columns tends to be quite limited. Maybe your database supports it, but do the drivers for that database in all the languages you might use support them? Will all that SQL tooling that you're so happy about handle the constructs that are needed to query into those JSON columns?

> Why not just use a SQL db that handles json and stick everything in a couple columns?

Honest question: what's wrong with just defining a domain model, adopting an ORM and a serialization framework, and simply go with a conventional RDBMS? Afaik all reference web application frameworks handle this right out of the box.

Nothing on paper, if you get the schema more or less correctly the first time. The problem is when you need to do a schema change that affects terabytes of data down the road.

That is going to be a problem regardless of technology.

With an enforced schema you will at least know that all of the existing data matches the schema. Without it you have to hope that you had zero bugs while collecting the terabytes of data.

Yeah, but it's a different type of problem.

If you've a schema, you sometimes need to rewrite an entire table as part of a migration, and that can mean heavy engineering if you want to avoid downtime or disabling writes during the migration. There are 1:1 relationships between tables in the wild that wouldn't have passed a sniff test as part of an early schema design review, but then got created regardless to avoid a lengthy table rewrite.

If you've no schema proper, by contrast, you can manage multiple variations of what the data might look like in code. Not that such a thing is simple; it's definitely not, for the reason you raised. But it's simpler to deploy and migrate, or certainly might appear to be so to someone who isn't comfortable with SQL.

Also, there's a class of apps where having a schema doesn't add much value and NoSQL actually makes sense. Think storing and mining logs, scraped data, ML training sets, etc. -- apps where it doesn't matter much however a big pile of data gets stored, so long as you can shovel through it in parallel or store it very fast.

With almost any language, you can enforce schema via the “ORM”. Yes I know it’s not really an ORM but you get the point.

You just answered your own question. If I’m only working with objects, why wouldn’t I just store everything as objects?

And most ORMs suck outside of LINQ based ones since they aren’t a part of the language.

Because you still have to write a layer between your web app and the database at the prototyping stage?

I can't just make calls from Html + JS to Postgres.

But I can with MongoDB

Or you can use something like Postgrest: http://postgrest.org

Or Hasura GraphQL Engine: https://github.com/hasura/graphql-engine

The ability to query, index etc. I believe is much more limited than regular Mongo, but you can correct me if I'm wrong. Also, it feels like a cludge.

RDBMS to me is to expensive in the churn and I've run into some deadly query scenarios.

As a non-storage expert I would just love one of those 2000's era 'object databases' to start with. We used to use them a lot in networking because they suited well to topology. I'm not sure they're much of a thing anymore however as I suggest JSON DB's are pretty close to it so there's no need for it.

But they fit developer's mentality really well.

In that case, I would loose the tooling around Mongo for supporting JSON docs - especially the C# Mongo LINQ driver.