Hacker News new | ask | show | jobs
by tyingq 2377 days ago
It happens to be Cassandra, but that did make me think about the way Amazon brands the Postgres compatible Aurora as "Aurora PostgreSQL".

That's pretty lousy of them to take advantage of the name. I imagine the uptake would be lower if it weren't in the name, and they had to settle for just saying "Postgres Compatible" in the description.

I also imagine AWS would come after me if I launched "XYZ Fargate" or similar.

1 comments

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.
I'm not talking about RDS.

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.

It is Postgres. It’s using the same source code as a base and it’s compatible with all Postgres tools.
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.
Who cares about the “storage backend”? How does that affect clients?
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".

That said, I dust that's pretty uncommon.