Live data from Hacker News

Amazon DocumentDB, with MongoDB compatibility

aws.amazon.com

221–230 of 323 posts

Re: Amazon DocumentDB, with MongoDB compatibility

#221
post #204

Earlier quoted context omitted.

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

In comparison to what?

Re: Amazon DocumentDB, with MongoDB compatibility

#222

Earlier quoted context omitted.

Have you heard of Amazon Elasticsearch Service, launched in 2015? Elastic is doing fine.

This is hopefully a good counterexample. Amazon's Elasticsearch Service is pretty bad (poor general performance, very slow to make cluster changes/launch new clusters, etc). But I can't help but think Amazon can and would easily fix those things if they mattered. Amazon's hosted Elasticsearch is a lot cheaper than Elastic's, and I'll bet that's enough to get people to use it.

> poor general performance

By poor performance, I assume you mean IO? AWS Elasticsearch has supported i3 instance type (nvme on-instance storage) for well over a year now [0]. Additionally, you could enable slow-logs to catch perf issues yourself [1]

> very slow to make cluster changes

Scale-out and access-policy changes happen in-place now and so happen much faster than they used to be.

> launch new clusters

In my experience, it depends on the cluster size, but usually, I see cluster being up in 20m. That's nice given that it sets up pretty much everything (spin up instances, apply access policies, run health checks, enable cloudwatch monitoring, snapshots, create route53 records, integrate with cognito, enc-at-rest via KMS, spin up load balancers, setup vpc resources etc) on my behalf.

[0] https://docs.aws.amazon.com/elasticsearch-service/latest/dev...

[1] https://aws.amazon.com/blogs/database/analyzing-amazon-elast...

Re: Amazon DocumentDB, with MongoDB compatibility

#223

Earlier quoted context omitted.

> I've never seen a SQL driver and wire protocol that was not awful in some way. Have you seen the PostgreSQL wire protocol[1]? I recently built a logical replication client driver for a project and found the protocol to be excellent. After looking at the documentation, I'm no longer limited to languages that have drivers for Pg, because I know how easy it'd be for me to just write one. Just because some SQL drivers…

An HTTP/JSON protocol doesn't have to replace the standard one. But having such a standard protocol makes sense in the age of web apps, particularly when NoSQL offerings that are perceived by the market as competitors (leaving aside whether they really are - perception matters more here) do that already.

> An HTTP/JSON protocol doesn't have to replace the standard one.

So, two protocols? Two standard protocols is rarely better than one.

> having such a standard protocol makes sense in the age of web apps

Only if the existing standard protocol cannot work with the "web", and we have plenty of history proving otherwise. Replacing the existing standard with the loose JSON would be, strictly, a downgrade; and unnecessary, because we already do interoperate JSON and SQL. See: PostgREST and the many REST & GraphQL frontends on PostgreSQL.

> particularly when NoSQL offerings that are perceived by the market as competitors (leaving aside whether they really are - perception matters more here) do that already

This is really more of going into a pig's pen and wrestling with them. A database should do the job of a database. Competing for perception in a market that cannot make sane decisions for itself is how we get MongoDB.

Re: Amazon DocumentDB, with MongoDB compatibility

#224
post #80

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

And there are organizations who can do rapid development in Postgres.

Re: Amazon DocumentDB, with MongoDB compatibility

#225

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

My assumption is that DocumentDB falls into a category of being so generic you can't trademark it, or otherwise claim exclusivity to it. Its literally just describing the fact this is a database for documents.

Re: Amazon DocumentDB, with MongoDB compatibility

#226

Earlier quoted context omitted.

Can you please elaborate? This was launched today, you had access to the new feature in advance?

Not OP, but that wouldn’t necessarily be a surprise. As customers make product requests to AWS they can be tapped to test upcoming launches - anything from pre-release testing to very early alphas.

I can confirm that this is very much a thing that they do. We have an account manager able to bump feature requests over to the appropriate product managers, and have been involved in pre-release testing of features that we expressed interest in.

Re: Amazon DocumentDB, with MongoDB compatibility

#227
post #168

Earlier quoted context omitted.

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.

Are you aware that they are working on multi-master for Aurora? https://aws.amazon.com/about-aws/whats-new/2017/11/sign-up-f...

Re: Amazon DocumentDB, with MongoDB compatibility

#228

Now I kinda hope Oracle decides to buy out MongoDB and integrate it into their own cloud. Then Oracle can decide to pull the same bullshit that they did with Google over the Java APIs with the MongoDB APIs but now against their current enemy Amazon (and Microsoft, too). Then a combined Google + Amazon + Microsoft may finally be able to reverse the API Copyright insanity that is hovering ominously over the tech indust…

I've always seen Google+Android as the good guys that gave Java new life while I saw Oracle has the bad guys that bought Sun and killed Java.

Re: Amazon DocumentDB, with MongoDB compatibility

#229

Of 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?

UPDATE: They are idiots.

Re: Amazon DocumentDB, with MongoDB compatibility

#230
I don't understand why people are reacting to it so aggressively. That's basically how AWS works, they did the same to Apach Kafka with Kinesis, Prestodb with Athena, PostgreSQL and MySQL with Aurora, Redis with ElastiCache and many others over the last 4 years so it's not new.

It took too long for the open-source community to figure out that the cloud providers are killing them, now it's too late. Well played, AWS.

Post reply on HN