I didn't see if there was a re:invent talk about it, but is it actuallly Cassandra under the hood? It seemed like it might just be the Cassandra API akin to Aurora being MySQL.
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.
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.
That's certainly the case at least for Aurora PostgreSQL, but then again, Aurora PostgreSQL lags MySQL significantly [1] in features; maybe that is related.
In the last write wins mechanism if two writes (V1 and V2) happen concurrently to different replicas why is V2 considered the last write in the article.
Reading the explanation and lead up, i was left with the impression that the last updates to each column (for a columnar store like Cassandra) would take effect so the final would be
Is it just me having inadequate vision or the visual design of the article is challenging? Light grey text on white background, dark red and blackish colors on dark grey background.
