Item — HN Reader

Aurora Postgres is a fork of Postgres code, with modifications that allow it to leverage AWS' Aurora storage, and a few other things (replicas, etc.).

The goal is to remain 100% Postgres compatible. So the network protocol, SQL queries, and tools, all can be used without any change. There are (were?) some (read: very few) caveats/restrictions, though, because of the heritage of, and need to be compatible with, Amazon RDS Postgres.

Disclosure: Member of the founding-team of Aurora Postgres; left the team quite a while back, so my knowledge is quite outdated.

Edit: There's a lot of literature, and public information (articles, conference talks, etc.) published by the Aurora team over the years, which all allude to these facts, and you can use that material to build your confidence that it is in fact Postgres compatible.

2 comments

Interesting, thanks for sharing this tidbit.

For no particularly good reason, I was under the impression Postgres Aurora was just a Postgres compatibility interface layer on top of a common substrate shared with the MySQL Aurora implementation.

Is this the same situation that came up with Elasticsearch?

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.