Top 9 Myths about MongoDB

MongoDB has been around for more than 15 years now. They grow up so fast. And since then, it has grown from this... MongoDB is okay for getting started, but I wouldn't use it in production. To this... MongoDB is still okay for getting started, but I wouldn't use it in production. Wait, what? Yeah, MongoDB is not ACID-compliant. Excuse me? It's not secure. Maybe for a niche task. I can't make joins with this. It doesn't scale. Whoa, whoa, whoa, whoa, whoa, whoa. Hold on. Okay, I get it. Such a long round comes with its fair share of myths and legends. These guys might need some clarification here and there. So stay around, because in this video, we will debunk the top 9 myths about MongoDB. MongoDB myth number 9. It doesn't have a schema. It's just a mess. MongoDB has a flexible schema, which is different from being schema-less. With flexible schema, developers are able to start building applications without having to design beforehand the definitive schema, then constraining themselves to it and requiring downtime for schema updates. MongoDB's flexible schema, on the other hand, just allows steps to hit the ground running. Now, after a schema has been decided upon, MongoDB allows developers to lock it, if they want, ensuring that every document in the collection has a consistent schema. However, will your schema require to evolve? Who knows. But most importantly, who cares? Unlike legacy relational databases, MongoDB also lets you switch between schema versions in your collections with absolutely no downtime. MongoDB myth number 8. MongoDB is not ACID-compliant. I mean, it's just a base database. MongoDB is ACID-compliant. Right off the bat, every time that you perform any CRUD operation on a single document, data integrity is preserved. MongoDB handles data one document at a time. Otherwise, it wouldn't be a document database. It would be a POSTED database. Everybody, right here, at the same time. Last ride wins! Now, I hear you say, what happens with multi-document transactions? Fear not, because with MongoDB, data loss is not an option. MongoDB guarantees multi-document asset transactions from and to any location in your MongoDB cluster. In fact, transactionality is one of MongoDB's greatest strengths. Many financial services companies, who are the kings of transactions, trust MongoDB transactions for core banking and trading use cases. The all-or-nothing guarantee of MongoDB multi-document transactions has got your back. MongoDB myth number 7 How am I supposed to handle relational data? I can't make joins with this. MongoDB can do joins with the $lookup command. But the fact that you can do something doesn't mean you should. MongoDB data is modeled in a different manner than tabular data. In MongoDB, data that's queried together is stored together. Hence, joins should not be necessary. This shift from the relational model to the document model can be challenging. I've been there too. However, if you're still required to do joins with MongoDB, the command $lookup is your best ally. Pro tip, you can even create a view to join two collections if you want to. MongoDB myth number 6 You can use it for some niche tasks, but nothing serious. MongoDB is a general-purpose database. This means that it was designed to be flexible, to adapt to your use case. MongoDB's document model provides users with a flexible schema that can be tailored to your needs. Pair this with MongoDB's horizontal scaling capabilities and an awesome query API, and boom, you get a beast of a database that adapts to the requirements and complexity of your use case. You can use MongoDB as your core database, to provide a single view of your data, to personalize content, build a catalog, mainframe modernization, gaming, AI, it's great to start with, it's awesome at scale, and it provides a smooth development experience for building modern future-proof applications. MongoDB myth number 5 It's okay for initial development, but I wouldn't let MongoDB anywhere near my critical data. MongoDB is a perfect suit for enterprise-grade mission-critical workloads. Atlas counts with 99.995% of uptime guarantee, blink and you'll miss it on a failover, absolute control about multi-region data sovereignty, and it is used in a wide variety of industries globally. In fact, MongoDB counts with the validation of 64 companies of the Fortune 100, 192 of the Fortune 500, 457 of the Fortune 2000, and has been repeatedly recognized as a leader by the top analyst firms Gartner and Forrester. Not only is MongoDB suitable for enterprise-grade usage, it has also been approved for government workloads, and it counts with some of the highest security certifications. An example of the industry proven MongoDB has become is Temenos, a global payments provider. Temenos utilizes MongoDB to serve more than 25 million buy-now-pay-later customers, to manage over 150 million loans, and to support the staggering number of, wait for it, 150,080 operations per second. MongoDB myth number four. It's not secure, at least not as secure as a relational database. MongoDB protects your data through its entire lifecycle, starting with client-side field-level encryption, data is encrypted before it's sent over the network to MongoDB. TLS and SSL protect your data over the network, and encryption address does so in the database. Furthermore, as a pioneering breakthrough, MongoDB offers queryable encryption, which protects your data while in use. This means that MongoDB doesn't need to decrypt your data to run queries against it. That is crazy. MongoDB also lets you choose your preferred authentication mechanism, and provides fine-grained rule-based access control, and auditing with log reduction. All these security features are right there for you to use, just don't forget to get them up and running after spinning up your cluster. Your data is in good hands. MongoDB myth number three. Looks like it's built for flexibility, so it must not be very performant. MongoDB provides you flexibility and versatility, but that doesn't mean that database performance takes the back seat. Every MongoDB component has been optimized so you get the most performant version of a document database at the lowest cost. But what happens to non-operational workloads such as search or analytics? Will those take a hit on your cluster's performance? Nope. That's why MongoDB provides workload isolation, to maintain every type of workload separate and highly performant. No ETL required. And what happens with latency of the network? That can only travel so fast. If you're required to minimize network latency because you had to place your primary node far, far away, MongoDB will allow you to read from the nearest secondary nodes. Want some examples of MongoDB performance? Amadeus, Comcast, Idealo, Temenos. And all these happened before MongoDB 8.0, the best performing version of the database, was released. With a 36% improvement for read-only workloads, 32% for reads and updates, 56% for bulk inserts, and a stunning 200% for time series queries. What a time to be alive! MongoDB myth number two. It's multi-cloud. So what? Many other databases are multi-cloud. MongoDB Atlas is multi-cloud, meaning that you can deploy a cluster in any of the three major cloud vendors. But do you know what's better than multi-cloud? Cross-cloud, aka inter-cloud, aka true multi-cloud. A cross-cloud deployment allows you to deploy in multiple clouds simultaneously, transparently, like if all the vendors just provided a single giant massive cloud offering. Why is this important? If there's an outage in this one, you can back your data up in another one. If this one got too expensive, okay, let's spin up a cluster in this other one. This one's not available where you need it, don't worry, we'll work on this other one that's available nearby. Really cool service in one cloud, but another cool service in another? Why not both? MongoDB myth number one. I get that it's built for horizontal scaling, but it's so painful to scale it. You know what's painful? Scaling relational databases is painful. MongoDB allows you to scale horizontally in three ways. Hash sharding, range sharding, and zone sharding. Hash sharding distributes data randomly across nodes. Range sharding allows you to fine-tune how your data is distributed according to a particular field, particularly useful to prevent hotspots. And zone sharding allows you to distribute your data territorially, which is extremely useful for compliance purposes and to reduce latency. So yeah, I'm gonna say it, MongoDB is way scalable. But what if you pick the wrong shard key or require cost correction at some point? Can you re-shard your collection? Absolutely yes. You can refine your shard key or just re-shard a collection with no downtime. And let's not forget, just because horizontal scaling is on offer, that doesn't mean good old vertical scaling is off the table. Just turn on auto-scaling, and we'll take care of that for you. And that's everything I have to say about MongoDB's myths and legends. Thanks for watching. MongoDB's web sca-