Live data from Hacker News

Amazon DocumentDB, with MongoDB compatibility

aws.amazon.com

201–210 of 323 posts

Re: Amazon DocumentDB, with MongoDB compatibility

#201

I really wish this were priced more along the lines of https://www.compose.com/pricing - a $200/m floor is a tough dB cost to absorb on smaller yet important projects. Suppose an app has a few mb of data and maybe one day hits 100mb of awesomeness I really have to pay $200/m here? I get it, I love Aws, just wish this was priced differently.

If you need a cheap/free document store for a small app, just use DynamoDB. It's free (forever, not just the first year) up to 25GB of storage and enough read/write capacity units to handle up to 200M requests per month: https://aws.amazon.com/free/?awsf.Free%20Tier%20Types=catego...

Exactly, this probably isn't targeting you. A few mb of data? Host an instance? Use sqlite? Atlas can run 3-5k/month as the minimum. This is going to be 10x cheaper (which amazon seems to try and shoot for).

Re: Amazon DocumentDB, with MongoDB compatibility

#202
post #150

Earlier quoted context omitted.

Oracle are the good guys in this scenario?

They always were the OK guys in that argument. Google invented a whole new VM and bastardized the language just to get out of a $1/device licensing fee for mobile uses. The Java ecosystem has been irreparably harmed by Dalvik and its lack of support for more modern versions of Java. On another note, anyone that doesn't think API design is a creative endeavor and worthy of protection probably has never made a great AP…

I also always found it amusing that people thought API design was not creative and protectable.

Like, “how many ways can you do a date api”, and then turn around to look at the original java Date api, the Calendar api, JodaTime and JSR310.

Re: Amazon DocumentDB, with MongoDB compatibility

#203

Earlier quoted context omitted.

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.

Only in tech do people think that a money losing company is “successful” because they were able to convince investors to buy stock instead of defining success as having a business model where income is greater than expenses. In reality long term profitability is the only metric that matters for a corporation

And in contrast to these startups with their "success" AWS is printing cash for amazon which releases surprisingly few "metrics" beyond $ in and $ out.

Re: Amazon DocumentDB, with MongoDB compatibility

#204
post #79

Earlier quoted context omitted.

What is the way out? Would love to hear from people.

There's no secret formula to stop people from competing with you. If MongoDB Inc is successful, it should be because they run a good document-database-as-a-service people want to use, not because they earn indefinite seigniorage from launching a popular open source project.

because they run a good document-database-as-a-service

Spoiler: they do not

Re: Amazon DocumentDB, with MongoDB compatibility

#206

Earlier quoted context omitted.

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.

People downvoting one of the guys who worked on DynamoDB at Amazon, somehow thinking they know better. HN in a nutshell.

Re: Amazon DocumentDB, with MongoDB compatibility

#207
post #4

Seems 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.

I’d be surprised to learn that AWS started and launched this project since the SSPL announcement. I suspect they began when latest Mongo was still AGPL, with no sign of impeding change.

Even though you're certainly right, Amazon offers 'real' options for Redis, MySQL, PostgreSQL, Elasticsearch, that all use upstream code. They will almost certainly never offer a similar thing for MongoDB.

Re: Amazon DocumentDB, with MongoDB compatibility

#209
post #167

Earlier quoted context omitted.

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 write…

I suspect that most MongoDB users never get to the point where they need to horizontally scale (i.e. it gets chosen for fad reasons, not because they actually have something big enough to scale).

And the nice thing about this hypothesis, you can test it by looking how successful DocumentDB will turn out to be. ~

Re: Amazon DocumentDB, with MongoDB compatibility

#210
post #167

Earlier quoted context omitted.

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 write…

Apparently SimpleDB is still used quite a lot internally. As for their market tactics, there's no denying it works as their pace is accelerating and leaving everyone else in the dust. Most customers just want to pay some money and have a solution ready to go, they don't need infinite scaling from day 1, if ever.

This focus on actually meeting needs today is what keeps AWS on top while the others take 2 years to launch minor service upgrades.

Post reply on HN