I'm pretty sure this is going to kill Mongo as a company dead. With this in existence there's literally no reason to use Atlas.
If they wanted to twist the knife they should get to work implementing a pass through migration option.
If they wanted to twist the knife they should get to work implementing a pass through migration option.
- control of the client and particularly its exposed featureset
- due to that, also control of the protocol and the ability to, for example, insert legally protected strings in the style of the Apple SMC signature into the handshake.
- ability to gate new features on the presence of an object like a copyrighted text, trademark, or even a crypto signature
- ownership of the name. AWS are pissing in Mongo's pool marketing themselves as compatible, and there are a variety of ways it could be made to backfire, if it were in Mongo's interests to encourage that outcome
- AWS focuses on breadth and very rarely nails any particular service. Their hosted Postgres for example still does not expose core features years later
- Following from that, AWS services on the whole are rarely best-in-class in terms of raw performance. I imagine Mongo could continue to easily compete on benchmark results running on AWS own infrastructure
I think this is a really interesting case, far more interesting than the technical minutia of Just Yet Another AWS service. It does not sit well with me whatsoever that they're basically ripping off a much smaller company's core tech while simultaneously borrowing their trademark (in a legally acceptable manner) as part of the marketing, but I also find it hard not to see a ton of potential upside from this for Mongo
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.
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...
I can also launch an Elasticsearch cluster myself in about 2 minutes via terraform, so 20 minutes is not super impressive.
That said I recognize Elasticsearch is actually quite a finicky beast to set up, and my setup only has to deal with the needs I have, and probably would be set up horribly for certain other people. I can see how a hosted system that has to deal with all the weird edge-cases of a few thousand customers would take longer to set things up.
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.
In reality long term profitability is the only metric that matters for a corporation