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.
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.
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.
That said, I dust that's pretty uncommon.
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.
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.
On the other hand, DocumentDB with Mongo Support doesn’t use any code from Mongo.
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.