3 ms·

I ran the preview for ~2 months on a few instances. No compatibility issues, but we had queries that were significantly slower than on a vanilla Postgres insta

I ran the preview for ~2 months on a few instances. No compatibility issues, but we had queries that were significantly slower than on a vanilla Postgres instance and a problem with temp table bloat that never got reclaimed (480G as per \l+, being shown as 1050G billable in the AWS console). The preview product team never got back to us so I'm going to switch back to the regular RDS this week and hope my bill doesn't get hosed by the unreclaimed bloat. Gotta go with the devil I know... ʅ(ツ)ʃ

jeffbarr 9y ago
Can you test this on the production version? I know that many issues were addressed during the preview period.
- nmilford 9y ago
  => select aurora_version(); aurora_version ---------------- 1.0.7 (1 row) Maybe it was solved and I need to build a new instance from snapshot to reclaim the space as an engine upgrade might not have done it. shrug I'll wait for the team to get back to me.
samstave 9y ago
Yeah, but AWS has a long history of "yeah, no problem - oops will just take that off your bill" -- so just ask them to do so. In fact, they are even proactive to the point where they come back and transparently have offered credits once their bills get fully baked. We had a launch loop happen when an AWS EC2 API went bonkers and so we couldnt query number of running instances, so our balancer logic thought it had none and launched thousands of machines... didnt cost a penny.
- justinjlynn 9y ago
  To be fair, amazon's actual cost in that case was probably predominately in the human time to review the case and credit the account. I doubt it cost them more than a few pennies in terms of cost of goods sold.
  - samstave 9y ago
    True, but the way they handled it was stellar.
    - justinjlynn 9y ago
      Oh, indeed. The interaction that probably cost them a few cents kept a very profitable customer coming back for more -- makes perfect sense.
markporter_aws 9y ago
I'm sorry the product team never got back to you. We'll get back to the email you just sent us on the preview thread. If you have any issues with your bill, let us know and we'll happily look into it. But I'd rather work with you to figure out what went on and get it fixed for you!
- brightball 9y ago
  I hope that’s what happens too. Another project I work on switched to Aurora for MySQL and it’s been phenomenal. Really hoping for a similar experience with Postgres.
- nmilford 9y ago
  Sure thing, feel free to reply to my email. \l+ shows 485 GB, and hitting temp_bytes from pg_stat_database is 0, but billable space is 1050G. I'd like to promote Aurora to production, but some of my system's 'legacy' queries which live behind an ORM are grinding against the Aurora instances. I haven't had need to really investigate/optimize the queries (or even try to pick apart what the ORM is doing) as the performance on the vanilla Postgres RDS instance wasn't was great, but wasn't problematic either, even on the db.t2.large's I'd use in lower environments vs db.r4.large's I'm using with Aurora. It may be that I am just missing something obvious.

jeffbarr 9y ago

Can you test this on the production version? I know that many issues were addressed during the preview period.

nmilford 9y ago
=> select aurora_version(); aurora_version ---------------- 1.0.7 (1 row) Maybe it was solved and I need to build a new instance from snapshot to reclaim the space as an engine upgrade might not have done it. shrug I'll wait for the team to get back to me.

samstave 9y ago

Yeah, but AWS has a long history of "yeah, no problem - oops will just take that off your bill" -- so just ask them to do so. In fact, they are even proactive to the point where they come back and transparently have offered credits once their bills get fully baked. We had a launch loop happen when an AWS EC2 API went bonkers and so we couldnt query number of running instances, so our balancer logic thought it had none and launched thousands of machines... didnt cost a penny.

justinjlynn 9y ago
To be fair, amazon's actual cost in that case was probably predominately in the human time to review the case and credit the account. I doubt it cost them more than a few pennies in terms of cost of goods sold.
- samstave 9y ago
  True, but the way they handled it was stellar.
  - justinjlynn 9y ago
    Oh, indeed. The interaction that probably cost them a few cents kept a very profitable customer coming back for more -- makes perfect sense.

markporter_aws 9y ago

I'm sorry the product team never got back to you. We'll get back to the email you just sent us on the preview thread. If you have any issues with your bill, let us know and we'll happily look into it. But I'd rather work with you to figure out what went on and get it fixed for you!

brightball 9y ago
I hope that’s what happens too. Another project I work on switched to Aurora for MySQL and it’s been phenomenal. Really hoping for a similar experience with Postgres.
nmilford 9y ago
Sure thing, feel free to reply to my email. \l+ shows 485 GB, and hitting temp_bytes from pg_stat_database is 0, but billable space is 1050G. I'd like to promote Aurora to production, but some of my system's 'legacy' queries which live behind an ORM are grinding against the Aurora instances. I haven't had need to really investigate/optimize the queries (or even try to pick apart what the ORM is doing) as the performance on the vanilla Postgres RDS instance wasn't was great, but wasn't problematic either, even on the db.t2.large's I'd use in lower environments vs db.r4.large's I'm using with Aurora. It may be that I am just missing something obvious.