Amazon Aurora Supports PostgreSQL 14

Pardon my ignorance but isn't dynamo just a document store itself? Most storage engines are designed and optimized for RDBs, so I'd expect inefficiency here unless there's a layer between them.

From one their talk the CTO hinted it was regular EBS.

But for many other database such as "Amazon DocumentDB" , "Time Series" humour suggest it's Dynamo.

+1 Aurora was the secret sauce for us to scale a db-heavy SaaS very quickly with no dedicated ops team. Got us an extra 9 in uptime, too. The cost difference from vanilla RDS was negligible for our revenue model. YMMV, of course on that.

Except... That's not always true. We were told the same, but we found the performance to be underwhelming, at best. Concurrent writes to the same row are orders of magnitude worse, certain read patterns are similarly slow, and you are severely limited in how many transactions you can have before the storage daemon gives up and you end up with double digit write latency for any write.

Yeah, for the most part it's better, but you lose the page cache buffer to stop you from running oom if you miscalculated your shared buffers, your cpu usage will go up significantly and sometimes things will be slower. While on paper the max IOPS are way higher, you do get more IOPS from migrating and then you run into other issues.

If you are or close to the 80k IOPS limit, or 65TB storage limit, there's no alternative, but the "aurora is always faster" line that AWS tries to sell you is bullshit.

It's a long story, but not exactly. Elasticsearch was developed independently by Shay Banon in 2010 and a couple others who are the founders of Elastic (http://www.elastic.co) under the Apache2 open source license. In March of 2015, Elastic acquired Found, a company offering cloud-hosted managed Elasticsearch clusters which became their "Elastic Cloud" product. In October of 2015, AWS launched their own managed Elasticsearch service called "AWS Elasticsearch Service". Werner Vogels announced it in a now-deleted tweet saying that it was a "great partnership between @elastic and #AWS" when, in fact, there was no partnership at all (thing https://www.theregister.com/2021/01/21/aws_not_ok_says_elast...). In January of 2021, Elastic changed the license under which Elasticsearch was developed from Apache2 to the "Elastic" license which allowed essentially all the same things as Apache2 (free use, modification, etc) so long as it was not used to provide a managed offering of Elasticsearch (https://www.elastic.co/blog/licensing-change). This was done because Elastic viewed itself as developing the Elasticsearch product that AWS immediately took and used for its own "AWS Elasticsearch Service" in competition against Elastic's own Elastic Cloud service which was a significant source of revenue for Elastic. Additionally, Elastic sued AWS for trademark infringement for the use of the "Elasticsearch" trademark in the "AWS Elasticsearch Service" name. In response, AWS forked the last Apache2 release of Elasticsearch and named their fork "OpenSearch". They also changed the name of their managed offering to the "AWS OpenSearch Service".

During the same timeframe, many other companies have seen the same risk of AWS taking their open source products and providing competing managed offerings and have chosen various methods of protecting themselves from AWS competition. Many of them (including MongoDB, MariaDB, Confluent, CockroachDB, Sentry.io, Apollo, Graylog, Couchbase) have adopted licenses such as the SSPL, BSL, and even the Elastic license that prevent or strongly discourage AWS from using their products in a managed offering. Others such as Grafana Labs have partnered with AWS (under undisclosed terms) for a managed offering. It's an ongoing tension between companies that want to offer an open source product with a managed offering that monetizes it.