Live data from Hacker News

Amazon DocumentDB, with MongoDB compatibility

aws.amazon.com

261–270 of 323 posts

Re: Amazon DocumentDB, with MongoDB compatibility

#261

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

Literally every S1 filing will have some sort of language like that. They are required to list the risks that may harm them.

Re: Amazon DocumentDB, with MongoDB compatibility

#262
post #5

Earlier quoted context omitted.

I love Azure for this. The names are almost all extremely straightforward. There are a handful that have made the jump from confusing to straight forward, and a handful that have made the jump from straightforward to confusing (CosmosDB, formerly DocumentDB, chiefly comes to mind).

Agreed. Too bad the Azure portal is the polar opposite. AWS, for all its faults, is mostly just a boring HTML portal but it works. Azure tried to get fancy, with side sliding panels all over the place, and it is barely useable. The nicest thing I can say is it is "quirky." It isn't really productive however, particularly not on my 1080p monitor at Windows 10's default 125% DPI. I literally quit Azure's Application In…

That's interesting. I actually quite like it. I can build monitoring dashboards for our various services an see how something I don't need to monitor is doing just by going to the panel for it. To each his own I suppose.

Re: Amazon DocumentDB, with MongoDB compatibility

#263

Earlier quoted context omitted.

Anecdote: I led a C# project where we could seamlessly switch back and forth between Mongo and SQL Server without changing the underlying LINQ expressions. We sent the expressions to the Mongo driver and they got translated to MongoQuery we sent the expressions to Entity Framework and they got translated to Sql Server.

C# is ahead of the game with LINQ, expression syntax, and the entire Rosyln platform. Passing an IQueryable around that can be interpreted and transformed for multiple backends is a incredibly productive. I wish more people knew about this, and .NET in general.

And I’ve seen a few Java and Javascript libraries that purport to “implement LINQ” and they don’t get the power of LINQ is not the syntax, it’s that LINQ translates your code to expressions that can be parsed and translated to any back end query - it’s not just an ORM.

I’ve seen a LINQ to REST API provider.

Re: Amazon DocumentDB, with MongoDB compatibility

#264
I hope AWS realises that harming OSS authors, even indirectly, is counterproductive to AWS' interests.

If Mongo dies, so does its userbase, and so does DocumentDB.

How to fix it classily? Contribute back with code maintenance or whatever customizations were developed in-house.

Also you get to save face - you are not perceived as a leech anymore.

Re: Amazon DocumentDB, with MongoDB compatibility

#265

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.

Another thought along these same lines is how do you host non-production (Dev, QA, Demo, etc.) environments without spending a fortune? Sure my production workload is 15TB but my development system is only running 15GB and I want to develop against what I deploy to.

If you can create schemas, that could be one solution.

I do this with Azure SQL Server instances, so a single instance can host all the 'non-critical' environments (dev, test, QA, demo) - works great!

Re: Amazon DocumentDB, with MongoDB compatibility

#266
post #261

Earlier quoted context omitted.

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.

Literally every S1 filing will have some sort of language like that. They are required to list the risks that may harm them.

They haven’t shown a profit yet. So you don’t have any proof that they have a sustainable business model.

Re: Amazon DocumentDB, with MongoDB compatibility

#267

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

Interesting- Reminds me, I wish Postgres would increase this default identifier limit to 255 - or make it easily user configurable. It can be done by a sophisticated user, but only via special compilation and only when first installed, which is a right pain. I find Long identifier names useful for constraint names and foreign key names auto generated by code.

Re: Amazon DocumentDB, with MongoDB compatibility

#268
post #255

Earlier quoted context omitted.

> They have a lever in front of them with two positions, one of which is "large cloud companies might use your software for free", and the other is "large cloud companies will not use your software at all". Was that even the goal? My impression of the licensing change was not that they expected to Amazon to pay fees for offering a hosted MongoDB service. It was instead to lock Amazon out, and keep MongoDB Inc. as the…

> My impression of the licensing change was not that they expected to Amazon to pay fees for offering a hosted MongoDB service. It was instead to lock Amazon out, and keep MongoDB Inc. as the only "cloud provider" of a hosted MongoDB service. Oh absolutely. I don't think they really thought they could force Amazon to license MongoDB, but I do think they believed they could force Amazon to not offer something that com…

I think PostgreSQL does benefit from Amazon RDS and Google Cloud SQL indirectly.

Unlike MongoDB, it is a real volunteer-led open-source projects, and the goal is to provide an excellent database to users rather than make money. Having easy-to-use cloud hosted versions available helps with attracting users, mindshare, and perhaps in the long run developers to the project itself. Having cloud hosted versions from big vendors means that it's easy to justify "we'll use PostgreSQL for this project" to management or clients.

Re: Amazon DocumentDB, with MongoDB compatibility

#269

Earlier quoted context omitted.

AWS prioritizes launch above EVERYTHING. It is their strategy, to have market tells them what to build. I think it works, and AWS has yet been brought down by this horizontal complexity. Quite an achievement, but might not be a satisfying experience for the engineers work there.

This is one of the main reasons why I don't like AWS services, everything just seems so half-finished. There's not a lot in AWS that I would trust enough to use in production. I wonder how widespread this view is. I suspect it's more widespread than Amazon realise. They may have optimised into a local maximum where they get a lot of value from being first to market, but could potentially get more by being first to "v…

I certainly agree that they seem half finished in terms of features and developer experience, but from the point of view of security and data durability they have an excellent reputation. They typically have a pretty good reliability story as well, but it relies on the customer architecture their solution to take advantage of multiple AZs/Regions, which is often not trivial.

As far as being "viable to trust a business on" the numbers don't lie, AWS is number one because customers are running their businesses on AWS. The fact that DocumentDB launched with supporting quotes from Capital One, Dow Jones and WaPo shows that customers were clamoring to use it even before GA.

Remember a lot of these customers are coming to AWS because they tried doing themselves and stuggled. When it comes to data, customers trust AWS more than they trust themselves, and rightly so.

Re: Amazon DocumentDB, with MongoDB compatibility

#270

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.

Bear in mind we're talking about the company that trademarked "Word" and "Excel" here.
Post reply on HN