Hacker News Reader

Comment by nusmella | Hacker News Reader

We have a 10TB database we switched from Aurora to Postgres and it cut out bill by 80%. However, there are some differences in our schema such as now using native partitions so it's hard to tell how much $ is due to the switch and how much due to our table and query design.

We have a similar story with DynamoDB too.

View on HN

Curious what you mean by switching from Aurora to Postgres? AWS offers Postgres on Aurora, and Postgres on regular RDS. Do you mean you switched to RDS, or off of AWS altogether, or something else?

Probably means Aurora MySQL. In CloudFormation and other AWS artifacts, "Aurora" is a keyword that regularly comes up meaning MySQL, since that was the original target for Aurora years before the Postgres flavor was released. There are AWS old-timers at my shop that call it Aurora, and it shows up in their YAML.

To whomever downvoted, when specifying the AWS::RDS::DBCluster "Engine" property in CloudFormation, aurora = mysql5.6 and below, aurora-mysql = mysql5.7 or mysql8.x, aurora-postgresql = postgres. Since 5.6 was deprecated, the "aurora" engine type was removed the CF docs, but it was there until a few years ago. "Aurora" was synonymous with MySQL for a while.

#AWSHistory

People downvoted because you were assuming that when someone says "we moved to postgres" they would mean "we moved to mysql" as if they wouldn't know what they were talking about.

Even your history thing makes no sense, Aurora Postgres was launched 9 months after Mysql version in July 2015.

> People downvoted because you were assuming that when someone says "we moved to postgres" they would mean "we moved to mysql" as if they wouldn't know what they were talking about.

What? That's not what that comment says at all. They're saying that aurora mysql was a plausible interpretation of what OP moved from, before OP clarified.

Yep, I was wrong about the source DB in retrospect, but that other guy just seems to want to argue with straw men. Takes all kinds, I guess.

Aurora MySQL was released October 2014.

https://aws.amazon.com/blogs/aws/highly-scalable-mysql-compa...

Aurora Postgres hit general availability October 2017. (Sorry, betas and early release offerings don't count.)

https://aws.amazon.com/blogs/aws/now-available-amazon-aurora...

Quick math… carry the two… compute the partial differential equation…

Looks like 3 YEARS between the release of Aurora MySQL and Aurora Postgres.

Yes, if you choose other definitions for launch dates you can come up with many different timespans.

You're right. I should use the GA announcement for Aurora MySQL as well.

…which was November 2015.

https://aws.amazon.com/blogs/aws/now-available-amazon-aurora...

So now tell me, between 7-9 years have gone by since Aurora is a multi database product, what sense does it make to assume its mysql? That's like saying at your company people call AWS "S3" or "SQS" because that's how it started. I don't even know what point you're trying to make because unless the majority of the time was mysql only and then recently other databases would've been added, the anecdote would still not make sense.

https://news.ycombinator.com/item?id=37085062

The majority of the time, it was identified as "aurora" in CloudFormation templates. 5.6 hit EOL in February of THIS YEAR, aka 2023.

https://aws.amazon.com/blogs/database/upgrade-amazon-aurora-...

So… that would make it the majority of time, wouldn't it? Why does this upset you so?

Someone disagreeing with you doesn't mean they are upset my friend. Have a good one because we're not going to agree.

I mean that we switched from RDS Aurora Postgres to RDS regular Postgres

> using native partitions

FWIW, I'm actively exploring native partitions on Aurora with Postgres and I'm seeing very little benefit. Two identical tables, each with 500M+ rows, and I'm not seeing any meaningful performance/IO changes. A composite index with the partition key as the first entry has been as effective for reducing IO and query time as partition pruning. I'm sure there are workloads where partitioning makes more sense, but I've been surprised by how little difference there was in this case.

> it's hard to tell how much $ is due to the switch and how much due to our table and query design.

Sounds like good material for a technical blog post.

What's the story with DynamoDB?

Reply on news.ycombinator.com