Jeff Bezos continues his quest to eat all open lunch boxes.
Microsoft was first with a MongoDB layer, like some 3 years ago I think. Nothing novel here from Amazon.
Amazon DocumentDB, with MongoDB compatibility
161–170 of 323 posts
Re: Amazon DocumentDB, with MongoDB compatibility
#162Of all possible names they managed to choose already obsolete name for a similar product from Azure? Azure in 2017: forget DocumentDB, Cosmos DB is the new thing now! AWS in 2019: We just released DocumentDB! Are they so geniuses or so idiots?
I had the same observation (although I'd reconsider your wording, that's not very polite). It doesn't seem like a good choice in naming - especially because many of the Data Platform folks at Amazon (like their VP) came from Microsoft's data platform group.
Re: Amazon DocumentDB, with MongoDB compatibility
#163Earlier quoted context omitted.
Ultimately, Cantrill put it well: > ...for those open source companies that still harbor magical beliefs, let me put this to you as directly as possible: cloud services providers are emphatically not going to license your proprietary software. I mean, you knew that, right? MongoDB Inc cannot make Amazon pay commercial license fees. That is not a thing that will happen. They have a lever in front of them with two posi…
Could Mongo or other companies use the Oracle v. Google precedent regarding API copyright to extract money from competitive vultures like Amazon?
I don't think so, isn't the API version they're using still covered under an Apache license?
Re: Amazon DocumentDB, with MongoDB compatibility
#164Earlier quoted context omitted.
Ultimately, Cantrill put it well: > ...for those open source companies that still harbor magical beliefs, let me put this to you as directly as possible: cloud services providers are emphatically not going to license your proprietary software. I mean, you knew that, right? MongoDB Inc cannot make Amazon pay commercial license fees. That is not a thing that will happen. They have a lever in front of them with two posi…
Could Mongo or other companies use the Oracle v. Google precedent regarding API copyright to extract money from competitive vultures like Amazon?
No, because the API was made open source as it’s just part of the MongoDB source code. Future changes to the API made under Mongo’s new license would in theory be eligible for such protection - but what that means in practice is anyone’s guess. For starters they would need to be “substantial”. I can’t imagine Mongo going down that road.
Re: Amazon DocumentDB, with MongoDB compatibility
#165Weird question: Could Microsoft sue Amazon here for infringing on the DocumentDB name? I mean Microsoft's DocumentDB was among the first to even have such a MongoDB layer also) and that was like 3 years ago.
Given that current Amazon leaders actually came from Microsoft's data platform group this leaves a bit of a bad taste behind.
I'm not working for either company.
Re: Amazon DocumentDB, with MongoDB compatibility
#166Earlier quoted context omitted.
Have you heard of Amazon Elasticsearch Service, launched in 2015? Elastic is doing fine.
Elastic Co isn’t profitable by definition it isn’t “doing fine”. From their SEC filing: https://www.sec.gov/Archives/edgar/data/1707753/000119312518... We have a history of losses and may not be able to achieve profitability or positive cash flows on a consistent basis. If we cannot achieve profitability or positive cash flows, our business, financial condition, and results of operations may suffer.
You're right they're not profitable — and neither is MongoDB — but the point is that AWS launched an Elasticsearch service 3 years prior to Elastic having a very successful IPO supported by stellar metrics (also found in the SEC filing you linked). So the statements made at the beginning of this thread are probably a bit premature.
Re: Amazon DocumentDB, with MongoDB compatibility
#167My bet is that it is built on top of Aurora PostgreSQL. By looking at the "Limits" section ( https://docs.aws.amazon.com/documentdb/latest/developerguide... ), identifiers are limited to 63 characters and the same characters that PostgreSQL limits identifiers to; and a collection size limit of 32TB, coincidentally maximum PostgreSQL table size. Edit: I can confirm: does not allow the UTF-8 null character in strings:…
It sounds like it is built on top of the Aurora storage subsystem that is used by both Aurora MySQl and Aurora Postgres[1]. I kinda expected them to build it on top of DynamoDb's backend and provide the same kind of "Serverless" on demand experience, but I guess the architecture didn't fit, or maybe this was just faster. 1. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
Definitely because it was faster. Amazon's strategy is to launch new features ASAP and then rely on everyone having to be on-call to fix shit when it inevitably breaks in prod because they rushed to launch. I will admit that while their "operational excellence" is shit, the security engineers do have quite a bit of power to block launches so their security isn't as bad as the reliability.
However, the fact that writes aren't horizontally scalable makes it a laughable nosql database but it probably satisfies the checkmark for enough of their enterprise customers that it will be a mild success and they'll keep it on life support like simpledb forever until they implement a proper solution assuming there is enough demand for it.
Re: Amazon DocumentDB, with MongoDB compatibility
#168Earlier quoted context omitted.
It would be nice if Amazon provided an API to access the data via SQL alongside the MongoDB API; I've seen quite a number of organizations migrate from mongo to Postgres once they get out of the rapid development phase. This would make that transition butter smooth.
I doubt that they actually built this on top of Postgres. They probably just integrated the WiredTiger[1] storage engine used by Mongo with their Aurora storage subsystem. I am however really hoping Amazon provides a MySQL 8.0 compatible version of Aurora with full support for its new hybrid SQL and Document Store interfaces[2] courtesy of the X DevAPI[3] and lightweight "serverless" friendly connections courtesy of…
> I doubt that they actually built this on top of Postgres.
Maybe not (but OP makes a lot of good points for why it is), but it is still based on the aurora limits, 64TB of size, 15 low latency read replicas in minutes, and presumably 1 write capacity which makes it a laughable nosql system since it cannot scale past 1 servers write capacity.
Re: Amazon DocumentDB, with MongoDB compatibility
#169Seems like this is likely to be the real result of licenses like the SSPL. Not even a terrible outcome if the different implementations remain relatively compatible.
SSPL style licenses only work if the software can't be cloned but that's a difficult assumption.
Operating systems, compilers, and web browsers come to mind. There are currently:
* 4 independently-developed competitive compilers (gcc, clang, msvc, icc)
* 4 independently-developed competitive operating systems (windows, macos, linux, and bsd --I'm grouping the BSDs as one since their source code has a common ancestor)
* 3 independently-developed competitive browser engines, soon-to-be 2 (edgehtml, gecko, webkit)
And it's been that way for a few decades now; doesn't look like anyone is interested in taking the resources to make another one of those.
Re: Amazon DocumentDB, with MongoDB compatibility
#170My bet is that it is built on top of Aurora PostgreSQL. By looking at the "Limits" section ( https://docs.aws.amazon.com/documentdb/latest/developerguide... ), identifiers are limited to 63 characters and the same characters that PostgreSQL limits identifiers to; and a collection size limit of 32TB, coincidentally maximum PostgreSQL table size. Edit: I can confirm: does not allow the UTF-8 null character in strings:…
It sounds like it is built on top of the Aurora storage subsystem that is used by both Aurora MySQl and Aurora Postgres[1]. I kinda expected them to build it on top of DynamoDb's backend and provide the same kind of "Serverless" on demand experience, but I guess the architecture didn't fit, or maybe this was just faster. 1. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
DynamoDB is written on top of MySQL (more specifically, MySQL's storage engine, not the query engine) so using Aurora which has a newer design would make sense.