I don't really agree there. The service is called documentDB and this is how they describe it [1]:

> Amazon DocumentDB (with MongoDB compatibility)

> Fast, scalable, highly available MongoDB-compatible database

And the first 2 sentences:

> Amazon DocumentDB (with MongoDB compatibility) is a fast, scalable, highly available, and fully managed document database service that supports MongoDB workloads.

> Customers use MongoDB as a document database to store, retrieve ...

You have to read all of that pretty carefully to understand that it's NOT MongoDB (a term they mention 5 times in the first 4 sentences). And if you read it carefully it seems to say it's compatible with MongoDB, whereas the Techcrunch article states it's only compatible with the MongoDB API from 2 years ago.

[1] https://aws.amazon.com/documentdb/

I disagree. If I see "Blah-compatible" I know it's not blah.

Digital Ocean is not advertising that they're AWS S3, just that they're S3 compatible. Like a processor that's x86 compatible, even though it's not actually an Intel 386, 486, etc. Like when computers used to advertise they were IBM compatible even though they're not an IBM PC. Like when store brands of toothpaste say "comparable to Colgate FreshWhite" but they're obviously not Colgate. Like when a startup calls themselves "Uber for horse rental" even though they're obviously not Uber.

We launched A1 instances with our Arm-Based AWS Graviton Processors to increase the selection of technology for our customers. It has nothing to do with demands of vendors, and everything to do with increasing choice, providing access to extensive technology ecosystems like those Arm has been building with their partners, and lowering costs.

Do you have a citation for that? AGPL is usually not considered business friendly or a corporate "allowed by default" license, even for internal use.

Contrary to the headline and articles inference I havent seen any indication that MongoDB source or IP is or was actually being used. As you note this all comes down to API compatibility and tangled notions of "proprietary" slash copyright.

But then there's even less reason to attack Amazon.

Completely agree with your conclusion, but is this not exactly what happened in Oracle v. Google?

So Oracle "owns" the Java API, but Google was allowed to clone that API to make Dvalik work with Java source code.

The same should be true of MongoDB's API. MongoDB Inc owns the copyright, but if someone wants to make a compatible API, they should be covered under fair use.

The result (so far) of Oracle v. Google is that Googler use was not fair use as a matter of law; that, however, was the result of an interlocutory appeal to the CAFC, and we still have further action at the district court for a judgement, and probably at least one more appeal up the chain, potentially the whole way to the Supreme Court, before we know the final outcome.

Which AWS service are you referring to exactly? AWS's existing json document DB is called DynamoDB and has nothing to do with Mongo.

The difference between AGPLv3 and the new SSPL applies to all work Mongo releasaes going forward. As intended, that difference will make it difficult for AWS to maintain compatibility, which the article points out is limited from the get-go.

They used Dynamo, and their white paper on it predates Mongo. Amazon was always an Oracle shop and now have dropped that too.

My old company begged AWS for years for Mongo, looks like they finally got around to it.

Self hosting MongoDB has always been a pain if you only have a small amount of data in it. The scaling goes one host, master/slave (which existed, though people would argue with you that it didn't), to 7+ separate hosts if you're going to build it properly (2x mongoose with DNS across them, 3x config cluster, 3x data cluster).

That's a hell of a jump for someone only using Mongo incidentally. You can cheat and combine multiple pieces of the cluster on single hosts but if that fails you can then get into weird multi-component failure issues.

I suspect the drive for DocumentDB was more because customers were asking them for it

You're just talking narrowly about Amazon in this comment. What you said makes more sense if you broaden it to commercial users. They might have known FAANG companies, esp Amazon, would just ditch their software if they switched licenses. They might be targeting the companies that can't or won't build a MongoDB knockoff. The companies that will actually pay for their product. That's a huge market.

There's no point in, or place for, spirit of the system vs letter of the system discussions or calls to morality. Mongo does not deserve to survive / exist if it can't make it's offering better than a competitors.

Would Mongo even exist as a company if it had launched as a contract only vendor? Pretty much not... so it can't demand to play both sides.

Oh the irony. Open source is just a development model, while Free Software, if anything, it meant to provide freedom to all users, not just business.

Reinforcing the public cloud oligopoly only reduces such freedom.

Well, write the licenses and let's see what traction they get. I'll wager that they will be shot down by pretty much everyone

Judging on your other comments, it doesn't look like you're familiar with MongoDB's historical shoddiness. I don't agree with you on practice in this case or any case. If MongoDB's company can't out-execute, then they should have never made their product open source to begin with (and in that case it probably would never have gotten as popular as it did). That's the bargain you have to make to try and monetize open source software -- you don't just get a business for free.

But beyond that, I don't agree with you on principle in this case, because I have nothing but disdain and scorn for MongoDB. Both MySQL and Postgres have fine support for unstructured data now, and provide the entire relational toolchest as well. That's not even getting into other multi-paradigm databases like CockroachDB or ArangoDB. I struggle to think of a use case that it is more appropriate for than another option; and indeed, every time I have had to deal with it in production, I have never thought that it was anything but a poor decision.

That’s bit harsh. MongoDB has its uses. Denormalized data struture make it very easy to scale for example. Being able to use JS everywhere is nice too.

That switches the subject from “do they add value?” to ”are they the first?”.

I would think the existence of other companies offering something similar is an indication that it adds value.

However, MongoDB selected a free and open source license. This was always in the cards. They went with AGPL to keep the source maximally open for end users, but that never protected their revenue stream. (Some JS SDK companies used it for that purpose, where it makes some sene, but a DB is very different.)

But if they had started with something proprietary uptake would have been very likely much less. And people would have continued to use mysql or Cassandra if they really needed something "webscale".

So they are trying to eat their cake and have it too.

I sort of agree with their sentiment, but of course they are late to the have-cake-will-have-it-and-eaten-it-too party, as now AWS was able to fork the last AGPL-ed version and be done with it.

Even if MongoDB goes out of business, or becomes less popular AWS benefits as they can keep selling to these "legacy" customers their super-stable AWSgoDB, and said customers will just eat it all up without thinking.

If only they had! But MongoDB is 1% technology and 99% marketing, they had no technological moat to speak of.

See also: Docker.