There are two separate offerings. AWS offers Aurora/Postgres which is a fork of Postgres with Amazon’s own code and there is regular RDS/Postgres which is basically managed Postgres.
The storage backend isn't Postgres, and I assume the repeated use of the words "compatible" and "wire protocol" is on purpose, so they can continue to change it.
I realise the parent comment is being voted down, but I think it’s a good point. If you’re buying a managed service, why should it matter if Amazon twiddled with how it stores data? What matters is that it behaves exactly like PostgreSQL in every way—which I’m led to believe it does.
There may be marginal resultant performance characteristics but they’re unlikely to be significant or wildly non-linear. My understanding is that this isn’t a storage engine rewrite, but a modification to the IO layer at the bottom of the storage engine.
Still, if you want “pure” anything, run it yourself.
Clients no, but if you have had a Postgres DBA optimize your database to take advantage of known Postgres storage backend behavior you may be in for unexpected performance degradation under the assumption "it's just Postgres".
Well, you get the same problem if you have “network administrators” who took one AWS certification and call themselves “AWS Consultants”.
In both cases you end up with suboptimal solutions. The lesson to learn is not that AWS shouldn’t be making storage optimizations, it’s that you don’t depend on a bunch of old school net ops “lift and shifters” who didn’t take the time to learn the environment and who think that the cloud is just an overpriced colo.
I'm talking about "Amazon Aurora PostgreSQL". That's what they call it. See this page, for example: https://aws.amazon.com/quickstart/architecture/aurora-postgr...
As mentioned, they likely wouldn't tolerate a "Tyingq Typhoon Fargate" that was my Fargate clone.