- Highly-flexible. Because you're not developing against a schema, you can, for example, retool a feature and its data quickly without having to stress about migrations. A big advantage for a startup looking to move fast.
- Queries look more like application code so you're not wasting mental cycles and time trying to translate an idea into a SQL query. From experience, this leads to less-fragile queries.
- Little to no concern over injection attacks (you have to go out of your way to create potential for them).
- Easier to write non-trivial queries than with SQL (IMO).
- Type-casting data can be done in code as opposed to with SQL you have to use inline, platform-specific functions like field_name::timestamp.
- A single source of truth for how to query and develop with it (with SQL, you're almost always developing against a flavor of it).
- Scales reasonably well (and easily) for a majority of use cases.
- No room for dogmatic fervor/confusion around a specific variety of MongoDB as there's only one variety.
> Because you're not developing against a schema, you can, for example, retool a feature and its data quickly without having to stress about migrations. A big advantage for a startup looking to move fast.
Why wouldn’t you need to worry about migrations without developing against a schema? You’ll need to worry more about migrations because your data will be more messy.
Not necessarily. If you're utterly careless, sure. A MongoDB migration is far less of a headache than a SQL one (you're just writing code to map/replace values). With SQL, you have to be frustratingly surgical about everything which can slow momentum to a crawl (read: punishment for mistakes in the migration is far worse than with MongoDB in my experience).
> Why wouldn’t you need to worry about migrations without developing against a schema? You’ll need to worry more about migrations because your data will be more messy.
If you're careless with your data, yes. "With great power comes great responsibility."
Mongo is the main nosql choice. Mongo is great if you think a flexible schema is good. Mongo is not great if you think a flexible schema is bad. That sums it up
This is too reductive, you can essentially have flexible schemas with most modern relational databases and without the downsides of document-based DBs.
In 99% of the cases, even if you need a flexible schema, PostgreSQL will remain the best choice.
I use it on-prem (well, on a VPS). It stores JSON documents, and it's easy to work with. If your data looks like a tree, it works pretty well, also for large documents. If you depend on relations between documents, you're better off with an SQL database, but note that for many cases --I'd say practically all mundane cases-- there's really no need for relations the SQL way. MongoDB also does relations, but a bit more convoluted.
But you don't need to horizontally scale if you use a beefy Postgres instance. Horizontal scaling is a problem created by using an inefficient DB in the first place.
I have DB clusters with masters with a terrabyte of ram. Going beyond that is a PITA with warming up cache, backups, and so on. There is a reason there's a huge industry for shared databases.
Also, query for query, Mongo isn't going to be that much slower than PG, and faster for some usage patterns...
It's a really great alternative to firebase for mobile apps. Works pretty nicely with Realm so you get offline first db with powerful syncing. All the benefits of realm on the edge device with the power of the mongo platform. I dismissed mongo atlas for years because "mongo", until I finally gave it a chance. Overall been pretty pleased.
We use MongoDB in conjunction with RealmDB to build an offline first mobile app. For this specifically it works very well. You basically define which parts of your document collection should be synced to which device, for example based on a query that contains the user id.
MongoDB takes care of syncing the right data to the right device when internet connection is available. On the device, the data is stored locally in RealmDB, which represents the other side of the sync.
This is not easy to do with PostgreSQL, which we use for all other scenarios requiring a DB.
- Queries look more like application code so you're not wasting mental cycles and time trying to translate an idea into a SQL query. From experience, this leads to less-fragile queries.
- Little to no concern over injection attacks (you have to go out of your way to create potential for them).
- Easier to write non-trivial queries than with SQL (IMO).
- Type-casting data can be done in code as opposed to with SQL you have to use inline, platform-specific functions like field_name::timestamp.
- A single source of truth for how to query and develop with it (with SQL, you're almost always developing against a flavor of it).
- Scales reasonably well (and easily) for a majority of use cases.
- No room for dogmatic fervor/confusion around a specific variety of MongoDB as there's only one variety.