MongoDB History (opens in new tab)

at large firms the clueless technology managment often buy based on the marketing crap, then force it down the throats of the engineers

at my firm we're being all but forced to use Azure even though it costs more and makes absolutely no sense whatsoever for the domain, but since it's the "technology strategy" fighting it becomes exceptionally difficult

Oracle's marketing is more to preserve their existing install base than acquire new customers.

Sounds like a bad architect or someone who only knows surface features and doesn't have experience with the actual databases.

Adding a column is not hard in any relational database, and pretty much all modern ones support no-downtime transactional schema updates with backfills, concurrent index builds, etc.

Also the schema always exists somewhere, and it's usually to put it in the database so it's next to (and validates) your data rather than keeping spread out in your application code.

Oh man. Payment provider data in mongo... even if by now MongoDB doesnt lose data... you REALLY want your ledger or OLTP to be in a relational, transactional database.

> Even Postgres gets it wrong sometimes

Imagining a timeline where people would say that about MongoDB is a good way to assess the project's quality...

MongoDB Inc. is still in the business of lying to its users through its teeth: https://news.ycombinator.com/item?id=23499658

And that's just a publicly available example. I have a client who paid for a MongoDB Inc. to send an "expert" down to assess the viability of a project, who flat out said the project can't be done and left it there; a week later the official MongoDB Inc. report says "We can definitely get it done. Why don't you move to our managed MongoDB Atlas service? That'll be $10K." For the record, my professional assessment was also that it'd be impossible to do it on a data model like Mongo's.

----

> Of course, there are those databases that are “perfect” from the start and never made any mistakes but is anyone talking about them today? Even Postgres gets it wrong sometimes.

1. The snark isn't helping your cause.

2. Then there are databases that claim to be "perfect" from the start, having always put up a facade without every admitting any of their own flaws. Like MongoDB.

The thing MongoDB does best — though not something a DBMS can be judged by — is marketing. Not just the marketing they push themselves — "MongoDB is web scale!", "90% of RDBMS use can be replaced by MongoDB!" — but also the marketing it can get its fans to push.

MongoDB is the fastest and easiest to scale schema-on-read document store.

So if your domain model is document orientated e.g. a star schema with dozens of joins, where you don't know the schema upfront or you have polymorphic relationships it is a really useful way to store your data.

Schemaless data (or at least schema-on-read rather than on-write) is the primary feature. Store JSON documents and index on any field.

Also it was great at sharding and scaling horizontally when first released, and one of the few options available at that time. It's since been eclipsed by much better systems that don't have such a convoluted and fragile setup.

These days there's not much benefit over a JSON field in a relational database, unless you're really invested in JSON/Javascript through your entire stack and want that to reach into the database as well.

I can share why I used it for 2 products (and regret not using it in 1): - if you are using an ORM library, it avoids unnecessary sync/migration steps by moving the schema definition only in the ORM (as opposed as in the ORM and synced to prostgres/mysql) - It is the fastest while used in-memory. I run the full suite of integration tests for a medium complexity api in 30 seconds. On one product (w/ postgres) we did run tests on sqlite but it's much slower (10x times). - It includes a lot of small features common in web sites or apis: media storage, queues, auto removal of old rows, full text search, geo queries. A dedicated solution (solr, s3, redis) would be better, but for small scale projects mongo was just fine (and a single thing to maintain, backup, monitor) - easy to learn, never hired someone with previous mongo experience, but it was never a problem: having a less expressive query language means that's easier

It is a free and open source NoSQL database that can horizontally scale if needed without any additional plumbing. A lot of projects use it due to its simplicity in developer workflow.

The problem of schemas slowing your development.

Cosmos' API is an emulation of MongoDB which differs in features, compatibility, and implementation from an actual MongoDB deployment. Cosmos' suggestion of API version support (eg 3.6) is referring to the MongoDB wire protocol rather than the full MongoDB server feature set for that version. There are also some inherent differences, such as Cosmos' Request Units (RUs) which need to be considered for capacity planning and costs: https://docs.microsoft.com/en-us/azure/cosmos-db/request-uni....

Those differences may be fine for some use cases, but definitely compromise portability if you want to run or test the same application with a database deployment on GCP, AWS, or your own infrastructure. The lowest common denominator is based on Cosmos DB's underlying limits and features (not a MongoDB server feature set): https://docs.microsoft.com/en-us/azure/cosmos-db/concepts-li....