MongoDB queries don’t always return all matching documents

Unless you have never written migrations in SQL before you would know that they are even scary and a big bunch of sql. What is even worse is that, despite nobody here acknowledging it, must SQL databases are used with an ORM. Now in your migration script you have to hack SQL and language-based ORM commands together into a big pile of shit.

> 2) Have schemas (except they'll be implicit and undocumented)

Actually they can be just as explicit and documented. Mongo even has schemas now I think. But you can see the schema in the class definitions of your code. Once again, most people use an ORM and do this anyway.

> 3) Constraints (except they'll be hidden inside your app logic, and violating them will cause data corruption).

Errr... SQL constraints are very limited and literally every application has additional constrains embedded in the code.

The PostgresSQL propaganda on this forum is such bullshit. None of you have any idea what you are talking about even though you are supposed to be hackers.

Not sure what that means, but scalability is the worst thing about mongo (though my experience with mongo is all from ~2.5 ish years ago). As soon as your working set of indices gets bigger than memory, performance falls off a cliff and your entire app grinds to a halt. In my experience, mysql and postgres have a more gradual decline in performance so you have some time with only mildly degraded performance to figure out a solution (plus they have more options for tuning which can buy you more time).

I agree with your last comment. I can't help but to laugh at people who think they would get away with designing a database with no schema. Schemaless for me meant that unless you enforce constraints, there won't be any.

There's a reason why there are ORMs even though Mongo drivers are sufficient for most cases.

1) I've always designed my data with future changes in mind. I often spend up to an hour thinking of possibilities of data that I want to store in a collection, before writing the schema. The flexibility i have with Mongo is that if I think I need a field but am unsure of the exact data type to store, i.e. is it a string or array of strings, or array of objects with strings? In that case I just leave the field as an object and change it later. The plus being that as long as I haven't stored anything with that field, I can always change its type without a 'migration script'.

I've only needed to 'migrate' by updating documents 4-5 time. When GeoJSON landed, and a few other times when I needed small changes to my data.

3) The only way I can think of enforcing constraints on I've used MongoDB primarily for its Geo support, and JSON enabling me to get things done quicker relative to maintaining SQL tables. I've got a small but interesting use case, public transit. https://movinggauteng.co.za and https://rwt.to.

When I started with the projects, PostgreSQL + PostGIS felt like a black box, and I wanted something that would give me ease and flexibility. At the time hstore was the talk of the day, but seemed to not meet my needs.

It would now with JSON, but I'll stick with Mongo for now.