merlynn

Yes. MongoDB enabled a standards-based approach to schemas back in 3.6... should you feel you need schemas. https://docs.mongodb.com/manual/core/schema-validation/

But with Atlas, you can VPC peer if you need that level of security and performance between your app and database. https://docs.atlas.mongodb.com/security-vpc-peering/

Michael from MongoDB here again. MongoDB Community is still free to view, download, modify, etc. The SSPL change affects no-one besides those offering the licensed software (MongoDB) as a public service.

I suppose but it might be interesting to note that you didn't have to wait for Amazon for that. A lot of people don't know that there exists a fully managed offering from MongoDB. It's called Atlas... not trying to sell here - just informing people that may read your comment and think it was a valid motivation for Amazon to create their DocumentDB offering. Atlas has existed for 2 years.

Not sure about the EFF but I know that MongoDB has submitted the SSPL to the OSI and has already taken feedback from that process.

Michael from MongoDB here... Greed? You realize that anyone can still view, download, use, develop, modify and do everything they could do prior to the change - right? The only difference is that if they decide to offer the licensed software as a public service they must release the other components of the service under the same license.

Michael from MongoDB here. Are you assuming RedHat is patching MongoDB at a rate more frequently than MongoDB itself - not the case. Also, there is NO additional cost per-server-license for MongoDB Community. You should know that you can simply subscribe to the latest version (as well as older versions) of maintained packages for various os's and distributions... and these are available at no charge. More information: https://docs.mongodb.com/manual/tutorial/install-mongodb-on-...

Michael from MongoDB here... Yep - MongoDB has continued to mature. Modern MongoDB supports multi-document ACID transactions if that's what you're asking. More information here - https://www.mongodb.com/blog/post/mongodb-multi-document-aci...

Michael from MongoDB here. Amazon, Microsoft, and Google are certainly big players in this field, and common wisdom is that they are best qualified to scale, but in this case, we have a clear counterexample. DocumentDB clusters are limited to a single region of AWS. MongoDB Atlas clusters can span the entire globe with low-latency reads and writes in multiple regions. In terms of pricing, DocumentDB is cheaper when you choose to go with 2 instances. AWS achieves this by shifting high availability to the storage layer which in turn means that any failover could require between 1 and 2 minutes to happen - this compares to seconds that this would take with MongoDB Atlas. If you go with the default DocumentDB configuration and use 3 instances you end up paying a premium between 20-35%. With this in mind, it really depends on your use case whether DocumentDB ends up being cheaper for you. In terms of reliability and the hosting service is global, Atlas currently outperforms DocumentDB.

Michael here from MongoDB - We're currently still running tests on users ability to change from MongoDB to DocumentDB. It may not be quite as simple as exporting and reimporting the data. Many features present in MongoDB 3.6 do not work in DocumentDB (https://docs.aws.amazon.com/documentdb/latest/developerguide...). Preliminary test results show that DocumenDB is closer to MongoDB 2.0 in its features (with some exceptions). That means people that choose to switch over will have to find workarounds and change their code to work with DocumentDB. We'll be releasing our analysis on this soon with more information.

Michael here from MongoDB - I can't answer your question about DocumentDB and Jepsen, but there is a more recent analysis from Jepsen: https://jepsen.io/analyses/mongodb-3-4-0-rc3. DocumentDB is built on Aurora, so the architecture is completely different.

MongoDB certainly can compete at scale with AWS with MongoDB Atlas - Managed Database as a Service.

In the spirit of complete transparency, I work at MongoDB. Depending on users' specific needs and the features of MongoDB they use, the differences could go quite a bit further than 'just' support. Some of the important differences to keep in mind include regional availability and approaches to resiliency (Atlas allows you to scale beyond a single node and offers multi-region clusters; DocumentDB limits you to a single primary), role-based access control (DocumentDB currently only supports user that has full access to all databases in a cluster; MongoDB allows fine-grained control), freedom from vendor lock-in (With MongoDB you can always choose to host your own clusters whereas DocumentDB does not afford you this option). These are only a few of the differences between the hosting platforms, on top of that, you would, of course, be limited to an incomplete set of features (https://docs.aws.amazon.com/documentdb/latest/developerguide...) compared to MongoDB 3.6 and you would be missing out on improvements available in MongoDB 4.0 and future versions.

Client privacy issues should not preclude the use of MongoDB Atlas... Atlas offers encryption of data at rest as well as the ability to manage your own keys.

Well that’s just a ridiculously uninformed statement. Of course mongodb scales horizontally. I can share many success stories of massive scale with mongodb.

1. Managing shards and the mongos router layer should not be dubious, IMHO. Additionally - there should not be a SPOF if you've designed the architecture to leverage the native scalability aspects of MongoDB. That said, if you struggle with management, you can certainly leverage an online service that greatly simplifies not only scalability but security, manageability, and availability as well.

2. I don't know the read/write profile of your app but based on the hundreds of apps I've helped to configure and size, I'd be inclined to suggest that you don't need a Redis cache if you're configured properly.

3. Interested in that roadmap... haven't seen it... what specifically interested you?

4. MongoDB has similar available... happy to share that with you.

You're certainly free to choose whatever solution you believe works best for your use case. However, the points you've made don't appear to provide compelling arguments for Couchbase over MongoDB.

No. Only when you make MongoDB Available to third parties as a service do you need to make the source code of your service available.