>The issue that Elastic had is that their entire business model was offering a managed elasticsearch solution. Amazon then created their own offering of the same thing

Amazon first offered Elasticsearch as a managed service in 2015. Elastic began offering managed services in 2018.

https://en.wikipedia.org/wiki/Elasticsearch#Managed_services

> since it is Amazon it was more tightly coupled with AWS and benefited from being a native AWS solution. There was simply no way for Elastic to compete with that.

That's one interpretation. I've another, which I've seen play out multiple times now across multiple OSS projects: company invents a thing, thinks that because they're the inventor of said thing they'll be able to sell a managed version of it, belatedly realise that inventing a piece of software doesn't magically make you the best in the world at running it at scale.

What Elastic, and most like them, can't compete with is the ability to run highly available/reliable software at the scale of Amazon.

Several years ago, I led a project at a startup to move from Postgres to Elasticsearch for geographic search. I chose Elasticsearch because it had the capability to do geohashing and so it provided a credible alternative to PostGIS for our particular use case. Geohashing-based search is particularly computationally intensive, which is somewhat different from traditional full-text search, which can be memory intensive.

I wanted to pay Elasticsearch to host our search cluster. And I did for a while. But it became clear we were paying for gobs of RAM that we weren't using and we didn't have enough CPU to really cover our search needs. I talked to the head of sales at the time and he said they were working on a plan that would allow us to choose machines that were more CPU heavy but that that was in the pipeline and there was no ETA.

So we switched to AWS and everything worked just fine.

All this is to say, Amazon was not offering the exact same service. They were offering a better service.