14 ms·

Heroku Postgres is now based on AWS Aurora

211 points by mebcitto 2y ago

metadat 2y ago
Product Storage Max Connection Monthly Pricing Essential-0 1 GB 20 $5 Essential-1 10 GB 20 $9 Essential-2 32 GB 40 $20 The pricing looks quite competitive, although I'm not sure what the prior rates were. 10 years ago I spent 10x+ per month for 32GB (RAM) Heroku Postgres instances, IIRC they were around $400/mo, maybe even more.
- fweimer 2y ago
  That's 750$/month now, I think: https://elements.heroku.com/addons/heroku-postgresql#pricing https://elements.heroku.com/addons/heroku-postgresql#pricing (Standard 4)
  - deleted 2y ago
    [deleted]
- SahAssar 2y ago
  > 10 years ago I spent 10x+ per month for 32GB (RAM) Heroku Postgres instances, IIRC they were around $400/mo, maybe even more. Aren't you comparing RAM vs Storage there? The pricing chart here says nothing about RAM.
- macNchz 2y ago
  These "Essential" tiers are bare bones instances for toys/mvps, they're much different than the bigger ones. No replication, 99.5% uptime target, no maintenance windows etc.
- ca_peterson 2y ago
  Heroku product here: the Essential 0 and 1 plans replace the older row-limited Heroku Postgres mini/basic plans at the same price points but better perf in a lot of scenarios and a storage instead of row limit - forcing people to denormalize for row count wasn't ideal under old mini/basic limits. The Essential-2 plan is a new option for a larger pre-prod/test/small-scale DB option above what we offered before. We're expanding the Aurora-backed offerings to include larger dedicated DBs in the relatively near future as well. Gail Frederick our CTO talked a bit more about it at high-level during re:Invent 2023: https://www.youtube.com/watch?v=fZLcv7rwj7Y&t=1955s https://www.youtube.com/watch?v=fZLcv7rwj7Y&t=1955s
  - vips7L 2y ago
    Why did I think you were leading the Apex product team?
    - ca_peterson 2y ago
      I was for quite a few years - moved to Heroku in Q3 last year for an interesting opportunity. Apex is in good hands with Daniel Ballinger (and I stay in touch with a bunch of team if that helps).
- mebcitto 2y ago
  I'm curious how the Essential plans work, given that Aurora pricing starts higher than that in monthly costs. It is probably databases in a shared multi-tenant Aurora instance, and then the single-tenant plans that are currently in pilot give you the full Aurora instance. That also explains some of the limitations and the low connection limits.
koromak 2y ago
Oroboros eating its tail
muratsu 2y ago
I don't know if it's still the case but a few years ago all major cloud providers were easily giving away thousands of dollars in cloud credits. I expect them to stop this soon since smaller cloud players build on top of them and offer better dx and startups prefer to work with these smaller companies despite free credits from larger players.
- willsmith72 2y ago
  > startups prefer to work with these smaller companies despite free credits from larger players Says who? My experience is the opposite - tending towards too much reliance on the main providers because of the credits
  - muratsu 2y ago
    Vercel is going strong - 25.5M in 2022, 100M in 2024. Netlify is currently at 30M. Add Supabase, Render, Railway, ...
    - rgbrenner 2y ago
      AWS alone is $100B/yr now
      - 8organicbits 2y ago
        Largely enterprise spend. Startups are a different market segment. They initially have small budgets, and eventually fail or grow large enough to move to different products.
  - teaearlgraycold 2y ago
    As a startup boy we are happily chewing through hundreds of thousands in GPU credits across all major cloud platforms + lambda labs. And once those credits run out we are planning to expand our owned training hardware. Currently we just have 3x L40S but would expand to 32x L40S. I’m excited to now be a sys admin in addition to a full stack web dev.
iancarroll 2y ago
Having previously been on several managed PostgreSQL providers and now on AWS Aurora -- Aurora has been pretty great in terms of reliability and performance with large row counts and upsert performance. However, Aurora isn't cheap and is at least ~80% of our monthly AWS bill. I wonder how it is cheaper than Heroku's previous offerings? Is it Aurora Serverless v2 or something like that to reduce cost? Aurora billing is largely around IOPS, and Heroku's pricing doesn't seem to reflect that.
- encoderer 2y ago
  Aurora has a new configuration option that changes billing from iops to higher storage costs. Might be what this is using.
  - iancarroll 2y ago
    Yeah, that’s what we use as well but I don’t think that addresses the underlying instance cost? I’m not familiar with Serverless v2 though, if that’s what this is using.
    - paulddraper 2y ago
      The instance cost is not much different then normal heroku compute
- drusepth 2y ago
  Heroku Postgres has always been priced on platform convenience with very high margins. It's been many years now so I don't remember the exact numbers, but I moved a few databases from Heroku to AWS and reduced my DB costs ~90% (magnitude ~900/mo --> ~100/mo) for roughly the same specs. They probably have a lot of margins to eat into before they need to adjust prices.
  - iancarroll 2y ago
    I am not seeing the margins in this $5/mo instance but I could be wrong!
colesantiago 2y ago
Genuine question, who even uses Heroku anymore? A VPS (hetzner, etc) + managed postgres DB (supabase / AWS / etc) or a local one might more more than enough these days.
- Andugal 2y ago
  For a lot of use cases, nothing beats « git push » and tada your app is deployed.
  - zdragnar 2y ago
    Very easy to do with GitHub actions or the equivalent in gitlab and probably other competitors by now I imagine. If you wanted to spend money on something else, circleci and others help manage ci/cd as well.
    - icedchai 2y ago
      Not to mention every cloud provider has something built in (AWS CodeBuild, GCP Cloud Build, etc.)
  - csjh 2y ago
    That’s a pretty standard feature nowadays
- risyachka 2y ago
  probably those who don't want to set uptime alerts, fine-tune configs, set up backups and restores (which are essential because sooner rather later someone always deletes a few rows/tables) and want to focus on business
- deleted 2y ago
  [deleted]
- davepeck 2y ago
  I do, as do several startups I advise. Despite interesting competition, my feeling is that the Heroku of 2024 remains... Heroku. I feel this way even though -- depending on how you segment -- the list of "interesting" competitors is quite long at this point: Render, Railway, Northflank, Fly.io, Vercel, DO App Platform, etc.
drewda 2y ago
I'm surprised to read this, given that both Heroku and Salesforce more broadly have hired what felt like a good number of PostgreSQL committers.
- tristan957 2y ago
  Which Postgres committers work at either of those companies?
hoomanmo 2y ago
here is the English translation: Amplify Might Be AWS's Worst Service, Bar None Confusing documentation, a mix of old and new systems, and it made a mess of my AWS account. To put it simply, over the past two days, I attempted to deploy a full-stack assignment on AWS services. The front end was written in React, using Vite as the framework. For such Single-Page Apps (SPAs), I personally prefer using specialized services like Netlify or Cloudflare Pages for deployment, as these services offer very robust CI/CD services, allowing for one-click deployment and automatic updates, saving a lot of hassle. Initially, I planned to manually deploy on AWS using the S3 + CloudFront model (since it was just a one-time assignment), but later I discovered that AWS has a service very similar to Netlify called Amplify, which also offers CI/CD one-click deployment services. Amplify goes even further by including user directory services, allowing for one-click registration and login via related components. It sounds great, but you only realize how problematic it is after using it. After some research, my initial deployment method was to upload the code to GitHub and then click the deploy button in the Amplify interface. This is also the deployment method I use most often with Netlify. However, I later found something wrong. The key issue was that applications deployed this way using Amplify couldn't directly use Amplify's UI components to access Cognito user directory services. After much searching, I found that Amplify has an Amplify CLI initialization command to create a new CI/CD project in the Amplify service, which also deploys additional resources like Cognito. It seemed feasible, so I did it. Then I found some issues. The initial "issues" were just on the AWS account management level: after deploying the project via Amplify CLI, my AWS account quickly filled up with a bunch of "things"—the reason "things" is in quotes is that Amplify created a lot of fragmented resources, including but not limited to CloudFormation, IAM roles, etc., even creating two Cognito identity pools for me—it's hard not to call them "junk." Moreover, most of these resources have names that are impossible for humans to remember or distinguish, and there are no explanations or grouping features to tell you what these things are for. If it were just like this, it wouldn't seem to impact the development process, right? The biggest problem is that the local debugging and production environment apparently don't use the same configuration files, and when I was cleaning up the automatically created resources in my AWS account earlier, I somehow deleted the roles calling the Cognito user pool in the production environment, causing the production environment to be unable to access the two user pools created by Amplify, constantly throwing 400 errors. After several rounds of "deploy-delete-redeploy-redelete," I decided to start over and look for the related documentation again. Later, I found that Amplify has a set of documentation outside of AWS's own documentation system, and this documentation recommends a deployment method: clicking the deploy button on the GUI webpage—yes, you heard it right, the same deployment method I used initially. So, how do you deploy additional components/services like Cognito this way? Amplify's answer is configuration files. As long as you create a folder for configuration files in the root directory of your project and write the corresponding configuration files in it, the cloud will automatically create the resources you need in AWS once it reads them. It sounds reasonable, right? Then you go to find the part about configuration files in the documentation... What's going on? Why can't I find anything in the search box in the documentation? There's not even a sample configuration file! Algolia indexing service can't be this bad, right? Searching for "defineAuth" in the Amplify official documentation returns mostly irrelevant information. Is my search method incorrect? I entered keywords like "site .amplify.aws defineAuth" in the Kagi.com search engine but couldn't find any examples or explanations of configuration file items. At this point, I'm completely convinced that the Amplify documentation is garbage. Fortunately, the API documentation of the Amplify framework is quite good, at least reducing my urge to buy a ticket to the US and blow up Amazon's headquarters while guessing the configuration file items... Also, Amplify has a UI that is completely different and more modern than other AWS services. The discrepancy is still a minor issue; the main problem is that if you create a project using the (slightly outdated) Amplify CLI, and then try to configure the back-end services like Cognito it deployed on the webpage, you'll enter an old interface. That is, once you click in, you see a slightly ugly but familiar interface, yet it feels completely disconnected from the previous Amplify interface... So now I understand why I hadn't heard of Amplify before—it's really hard to use. Complete integration is indeed an advantage, but even being born with a silver spoon doesn't excuse Amplify's messiness, simply throwing everything together and telling users "it just works." Users look at it, wondering what on earth all these things are, and then you hand them a manual that looks fancy but has zero information. Users, flipping through this tome with no useful information, can only throw this pile of stuff into the historical junk heap behind them in frustration. Some rights reserved Except where otherwise noted, content on this page is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International license. ENJOY READ THIS Short story: "The Cry of Accelerated Demise" in a place accelerating towards demise.
mattacular 2y ago
Aurora is probably the best managed database solution out there but it is not cheap.
- sgarland 2y ago
  RDS beats it in almost every aspect. Running your own on native NVMe blows both of them out of the water for performance and price. I am not a fan of Aurora. I don’t get the appeal at all. I’ve tried MySQL and Postgres varieties; it’s just expensive for no reason.
  - ghiculescu 2y ago
    What makes RDS better than Aurora?
    - sgarland 2y ago
      To be clear, my comment stated RDS is better "in almost every aspect." Aurora is better at one [0] thing – storage scaling. You do not have to think about it, period. Adding more data? You get more storage. Cleaned out a lot of cruft? The storage scales back down. Aurora splits out the compute and storage layers; that's its secret sauce. At an extremely basic level, this is no different from, for example, using a Ceph block device as your DB's volume. However, AWS has also rewritten the DB storage code (both MySQL/InnoDB and Postgres). InnoDB has a doublewrite buffer, redo log, and undo log. Postgres has a WAL. Aurora replaces all of this [1] with something they call a hot log. Writes enter an in-memory queue, and are then durably committed to the hot log, before other asynchronous actions take place. Once 4/6 storage nodes (which are split across 3 AZs) have ACK'd hot log commit, the write is considered persisted. This is all well and good, but now you've added additional inter-process latency and network latency to the performance overhead. Additionally, the storage scaling I mentioned brings with it its own performance implications. If you're doing a lot of writes, you'll encounter periodic performance hits as the Aurora engine allocates new chunks of storage. Finally, even for reads, I do not believe their stated benchmarks. I say this because I have done my own testing with both MySQL and Postgres, and in every case, RDS matched or beat (usually the latter) Aurora's performance. These tests were fairly rigorous, with carefully tuned instances, identical workloads, realistic schema and queries, etc. For cases where pages have to be read from disk, I understand the reason – the additional network latency of the Aurora storage engine seems to be higher than that of EBS. I do not understand why a fully-cached read should take longer, though. As a further test, I threw in my quite ancient Dell servers (circa 2012) for the same tests. The DB backing disk was on NVMe over Ceph via Mellanox, so theoretical speeds _should_ be somewhat similar to EBS, albeit of course with less latency since everything is in a single rack. My ancient hardware blew Aurora out of the water every single time, and beat or matched RDS (using the latest Intel instance type) almost every time. [0]: Arguably, it's also better at globally distributed DB clusters with loose consistency requirements, because it supports write forwarding. A read replica in ap-southeast-1 can accept writes from apps running there, forward them to the primary in us-east-1, and your app can operate as though the write has been durably committed even though the packets haven't even finished making it across the ocean yet. If and only if your app can deal with this loosened consistency, you can dramatically improve performance for distant regions. [1]: https://d1.awsstatic.com/events/reinvent/2019/REPEAT_Amazon_Aurora_storage_demystified_How_it_all_works_DAT309-R.pdf https://d1.awsstatic.com/events/reinvent/2019/REPEAT_Amazon_...
canadiantim 2y ago
People still use heroku?
eranation 2y ago
Happy Aurora Postgres serverless customer here. Be sure to use pgbouncer (self hosted, but it needs minimal babysitting) if you intend to use it in a serverless environment (and even if you are not, the benefits of not having to worry about connection pool exhaustion are still worth it). AWS's proxy won't work too well with prepared statements connection pooling (something known as connection pinning). EDIT: and yes, it's not cheap
olau 2y ago
A warning about Aurora: It's opaque tech. I've been on a project that switched to it by recommendation by the hosting provider, and had to switch away because it turns out that it does not support queries requiring temporary storage, i.e. queries exceeding the memory of the instances. It manifested the way that the Aurora instances would use up their available (meagre) memory, then start thrashing, taking everything down. Apparently the instances did not have access to any temporary local storage. There was no way to fix that, and it took some time to understand. After having read all the little material I could find on Aurora, my personal conclusion is that Aurora is perhaps best thought of as a big hack. I think it's likely there are more gotchas like that. We moved the database back to a simple VM on SSD, and Postgres handled everything just fine.
- orf 2y ago
  The first result on Google shows that Aurora certainly does have temporary local storage https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
  - alexey-salmin 2y ago
    I believe this issue is (or was) real. There are important differences in how Aurora treats temporary data. Normal postgres and rds postgres write it into the main data volume (unless configured otherwise). Aurora however always separates shared storage from local storage and it's not entirely clear to me what is this local storage physically for non-read-optimized instance types. The only way to increase it is to increase the instance size. [1][2] This is indeed frustrating because with postgres or rds postgres you just increase the volume and that's it. Luckily since November 2023 it also has r6gd/r6id classes with local NVMEs for temp files. [3] This should in theory solve this problem but I haven't tried it yet. [1] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.TroubleshootingStorage.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide... [2] https://www.reddit.com/r/aws/s/sIhBQhsG80 https://www.reddit.com/r/aws/s/sIhBQhsG80 [3] https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-aurora-postgresql-optimized-reads/ https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-au...
bingemaker 2y ago
After Heroku pulled their stunt in India when RBI changed some credit card rules, Heroku is pretty much history for me. They screwed small customers got rid of them saying they can't charge credit cards with new regulations. However they continued to entertain large customers from India. Never recommending them to anyone anymore
- holografix 2y ago
  You severely underestimate what a clusterfuck of credit card abuse comes out of India. Heroku used to lose millions a year.
  - bingemaker 2y ago
    Care to shed some more light?
- doutatsu 2y ago
  Same - I've been slowly migrating to Render (https://render.com https://render.com) as my new favourite.
gregorvand 2y ago
Can you still see all instances with their IDs on a shared cluster when you connect?
tbarbugli 2y ago
RDS is such a depressing database option. It does not matter how much money you throw at it, its performance will always be limited by the awful disk IOPS. Luckily these days you can easily run PG on EC2 (or simply use CRDB). Weird for Heroku to ignore this huge efficiency opportunity.
- p0seidon 2y ago
  Have you tried io2 in this context? Did not have the chance yet.
  - tbarbugli 2y ago
    io2 is generally better than io1, one advantage is that you can scale storage size and IOPS independently. That being said, RDS with io2 is still worse than an ec2 instance with nvme (a lot worse)
    - p0seidon 2y ago
      Yes agree every bare metal server probably beats EBS but a lot of manual work needed then.
breadwinner 2y ago
Google has 2 Postgres implementations: Cloud SQL and AlloyDB. How do they compare against AWS Aurora, for the heroku scenario, i.e., multi-tenant database?
PeterZaitsev 2y ago
Ah, I wish they would rather choose Neon... to get all the cool functions developers need but avoid going all the way proprietary.
nikita 2y ago
(CEO of Neon.tech) Aurora is one of the few real innovations in the database space recognized by SIGMOD: https://sigmod.org/sigmod-awards/citations/2019-sigmod-systems-award/ https://sigmod.org/sigmod-awards/citations/2019-sigmod-syste... It provides a lot of benefits to the user and also a ton more to the service provider. Specifically you don’t overprovision storage or compute. Plus at least theoretically you can provide invite IO throughput at the storage level. There has been a couple more iterations on the design since. Microsoft separated transaction log from storage: https://www.microsoft.com/en-us/research/uploads/prod/2019/05/socrates.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0... Neon added an object store and branches so you can integrate backups and add a Time Machine. PolarDB separated memory from compute - this makes serverless compute more nimble and unties memory and CPU.
richardgill88 2y ago
We're building on top of Aurora at https://xata.io https://xata.io. Currently our Aurora instances are in private beta. If you're interested in trying it out, drop me an email: richard@xata.io
ElectricBoogie 2y ago
[flagged]

211 points by mebcitto 2y ago

Product Storage Max Connection Monthly Pricing Essential-0 1 GB 20 $5 Essential-1 10 GB 20 $9 Essential-2 32 GB 40 $20 The pricing looks quite competitive, although I'm not sure what the prior rates were. 10 years ago I spent 10x+ per month for 32GB (RAM) Heroku Postgres instances, IIRC they were around $400/mo, maybe even more.

fweimer 2y ago
That's 750$/month now, I think: https://elements.heroku.com/addons/heroku-postgresql#pricing https://elements.heroku.com/addons/heroku-postgresql#pricing (Standard 4)
- deleted 2y ago
  [deleted]
SahAssar 2y ago
> 10 years ago I spent 10x+ per month for 32GB (RAM) Heroku Postgres instances, IIRC they were around $400/mo, maybe even more. Aren't you comparing RAM vs Storage there? The pricing chart here says nothing about RAM.
macNchz 2y ago
These "Essential" tiers are bare bones instances for toys/mvps, they're much different than the bigger ones. No replication, 99.5% uptime target, no maintenance windows etc.
ca_peterson 2y ago
Heroku product here: the Essential 0 and 1 plans replace the older row-limited Heroku Postgres mini/basic plans at the same price points but better perf in a lot of scenarios and a storage instead of row limit - forcing people to denormalize for row count wasn't ideal under old mini/basic limits. The Essential-2 plan is a new option for a larger pre-prod/test/small-scale DB option above what we offered before. We're expanding the Aurora-backed offerings to include larger dedicated DBs in the relatively near future as well. Gail Frederick our CTO talked a bit more about it at high-level during re:Invent 2023: https://www.youtube.com/watch?v=fZLcv7rwj7Y&t=1955s https://www.youtube.com/watch?v=fZLcv7rwj7Y&t=1955s
- vips7L 2y ago
  Why did I think you were leading the Apex product team?
  - ca_peterson 2y ago
    I was for quite a few years - moved to Heroku in Q3 last year for an interesting opportunity. Apex is in good hands with Daniel Ballinger (and I stay in touch with a bunch of team if that helps).
mebcitto 2y ago
I'm curious how the Essential plans work, given that Aurora pricing starts higher than that in monthly costs. It is probably databases in a shared multi-tenant Aurora instance, and then the single-tenant plans that are currently in pilot give you the full Aurora instance. That also explains some of the limitations and the low connection limits.

koromak 2y ago

Oroboros eating its tail

muratsu 2y ago

I don't know if it's still the case but a few years ago all major cloud providers were easily giving away thousands of dollars in cloud credits. I expect them to stop this soon since smaller cloud players build on top of them and offer better dx and startups prefer to work with these smaller companies despite free credits from larger players.

willsmith72 2y ago
> startups prefer to work with these smaller companies despite free credits from larger players Says who? My experience is the opposite - tending towards too much reliance on the main providers because of the credits
- muratsu 2y ago
  Vercel is going strong - 25.5M in 2022, 100M in 2024. Netlify is currently at 30M. Add Supabase, Render, Railway, ...
  - rgbrenner 2y ago
    AWS alone is $100B/yr now
    - 8organicbits 2y ago
      Largely enterprise spend. Startups are a different market segment. They initially have small budgets, and eventually fail or grow large enough to move to different products.
- teaearlgraycold 2y ago
  As a startup boy we are happily chewing through hundreds of thousands in GPU credits across all major cloud platforms + lambda labs. And once those credits run out we are planning to expand our owned training hardware. Currently we just have 3x L40S but would expand to 32x L40S. I’m excited to now be a sys admin in addition to a full stack web dev.

iancarroll 2y ago

Having previously been on several managed PostgreSQL providers and now on AWS Aurora -- Aurora has been pretty great in terms of reliability and performance with large row counts and upsert performance. However, Aurora isn't cheap and is at least ~80% of our monthly AWS bill. I wonder how it is cheaper than Heroku's previous offerings? Is it Aurora Serverless v2 or something like that to reduce cost? Aurora billing is largely around IOPS, and Heroku's pricing doesn't seem to reflect that.

encoderer 2y ago
Aurora has a new configuration option that changes billing from iops to higher storage costs. Might be what this is using.
- iancarroll 2y ago
  Yeah, that’s what we use as well but I don’t think that addresses the underlying instance cost? I’m not familiar with Serverless v2 though, if that’s what this is using.
  - paulddraper 2y ago
    The instance cost is not much different then normal heroku compute
drusepth 2y ago
Heroku Postgres has always been priced on platform convenience with very high margins. It's been many years now so I don't remember the exact numbers, but I moved a few databases from Heroku to AWS and reduced my DB costs ~90% (magnitude ~900/mo --> ~100/mo) for roughly the same specs. They probably have a lot of margins to eat into before they need to adjust prices.
- iancarroll 2y ago
  I am not seeing the margins in this $5/mo instance but I could be wrong!

colesantiago 2y ago

Genuine question, who even uses Heroku anymore? A VPS (hetzner, etc) + managed postgres DB (supabase / AWS / etc) or a local one might more more than enough these days.

Andugal 2y ago
For a lot of use cases, nothing beats « git push » and tada your app is deployed.
- zdragnar 2y ago
  Very easy to do with GitHub actions or the equivalent in gitlab and probably other competitors by now I imagine. If you wanted to spend money on something else, circleci and others help manage ci/cd as well.
  - icedchai 2y ago
    Not to mention every cloud provider has something built in (AWS CodeBuild, GCP Cloud Build, etc.)
- csjh 2y ago
  That’s a pretty standard feature nowadays
risyachka 2y ago
probably those who don't want to set uptime alerts, fine-tune configs, set up backups and restores (which are essential because sooner rather later someone always deletes a few rows/tables) and want to focus on business
deleted 2y ago
[deleted]
davepeck 2y ago
I do, as do several startups I advise. Despite interesting competition, my feeling is that the Heroku of 2024 remains... Heroku. I feel this way even though -- depending on how you segment -- the list of "interesting" competitors is quite long at this point: Render, Railway, Northflank, Fly.io, Vercel, DO App Platform, etc.

drewda 2y ago

I'm surprised to read this, given that both Heroku and Salesforce more broadly have hired what felt like a good number of PostgreSQL committers.

tristan957 2y ago
Which Postgres committers work at either of those companies?

hoomanmo 2y ago

here is the English translation: Amplify Might Be AWS's Worst Service, Bar None Confusing documentation, a mix of old and new systems, and it made a mess of my AWS account. To put it simply, over the past two days, I attempted to deploy a full-stack assignment on AWS services. The front end was written in React, using Vite as the framework. For such Single-Page Apps (SPAs), I personally prefer using specialized services like Netlify or Cloudflare Pages for deployment, as these services offer very robust CI/CD services, allowing for one-click deployment and automatic updates, saving a lot of hassle. Initially, I planned to manually deploy on AWS using the S3 + CloudFront model (since it was just a one-time assignment), but later I discovered that AWS has a service very similar to Netlify called Amplify, which also offers CI/CD one-click deployment services. Amplify goes even further by including user directory services, allowing for one-click registration and login via related components. It sounds great, but you only realize how problematic it is after using it. After some research, my initial deployment method was to upload the code to GitHub and then click the deploy button in the Amplify interface. This is also the deployment method I use most often with Netlify. However, I later found something wrong. The key issue was that applications deployed this way using Amplify couldn't directly use Amplify's UI components to access Cognito user directory services. After much searching, I found that Amplify has an Amplify CLI initialization command to create a new CI/CD project in the Amplify service, which also deploys additional resources like Cognito. It seemed feasible, so I did it. Then I found some issues. The initial "issues" were just on the AWS account management level: after deploying the project via Amplify CLI, my AWS account quickly filled up with a bunch of "things"—the reason "things" is in quotes is that Amplify created a lot of fragmented resources, including but not limited to CloudFormation, IAM roles, etc., even creating two Cognito identity pools for me—it's hard not to call them "junk." Moreover, most of these resources have names that are impossible for humans to remember or distinguish, and there are no explanations or grouping features to tell you what these things are for. If it were just like this, it wouldn't seem to impact the development process, right? The biggest problem is that the local debugging and production environment apparently don't use the same configuration files, and when I was cleaning up the automatically created resources in my AWS account earlier, I somehow deleted the roles calling the Cognito user pool in the production environment, causing the production environment to be unable to access the two user pools created by Amplify, constantly throwing 400 errors. After several rounds of "deploy-delete-redeploy-redelete," I decided to start over and look for the related documentation again. Later, I found that Amplify has a set of documentation outside of AWS's own documentation system, and this documentation recommends a deployment method: clicking the deploy button on the GUI webpage—yes, you heard it right, the same deployment method I used initially. So, how do you deploy additional components/services like Cognito this way? Amplify's answer is configuration files. As long as you create a folder for configuration files in the root directory of your project and write the corresponding configuration files in it, the cloud will automatically create the resources you need in AWS once it reads them. It sounds reasonable, right? Then you go to find the part about configuration files in the documentation... What's going on? Why can't I find anything in the search box in the documentation? There's not even a sample configuration file! Algolia indexing service can't be this bad, right? Searching for "defineAuth" in the Amplify official documentation returns mostly irrelevant information. Is my search method incorrect? I entered keywords like "site .amplify.aws defineAuth" in the Kagi.com search engine but couldn't find any examples or explanations of configuration file items. At this point, I'm completely convinced that the Amplify documentation is garbage. Fortunately, the API documentation of the Amplify framework is quite good, at least reducing my urge to buy a ticket to the US and blow up Amazon's headquarters while guessing the configuration file items... Also, Amplify has a UI that is completely different and more modern than other AWS services. The discrepancy is still a minor issue; the main problem is that if you create a project using the (slightly outdated) Amplify CLI, and then try to configure the back-end services like Cognito it deployed on the webpage, you'll enter an old interface. That is, once you click in, you see a slightly ugly but familiar interface, yet it feels completely disconnected from the previous Amplify interface... So now I understand why I hadn't heard of Amplify before—it's really hard to use. Complete integration is indeed an advantage, but even being born with a silver spoon doesn't excuse Amplify's messiness, simply throwing everything together and telling users "it just works." Users look at it, wondering what on earth all these things are, and then you hand them a manual that looks fancy but has zero information. Users, flipping through this tome with no useful information, can only throw this pile of stuff into the historical junk heap behind them in frustration. Some rights reserved Except where otherwise noted, content on this page is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International license. ENJOY READ THIS Short story: "The Cry of Accelerated Demise" in a place accelerating towards demise.

mattacular 2y ago

Aurora is probably the best managed database solution out there but it is not cheap.

sgarland 2y ago
RDS beats it in almost every aspect. Running your own on native NVMe blows both of them out of the water for performance and price. I am not a fan of Aurora. I don’t get the appeal at all. I’ve tried MySQL and Postgres varieties; it’s just expensive for no reason.
- ghiculescu 2y ago
  What makes RDS better than Aurora?
  - sgarland 2y ago
    To be clear, my comment stated RDS is better "in almost every aspect." Aurora is better at one [0] thing – storage scaling. You do not have to think about it, period. Adding more data? You get more storage. Cleaned out a lot of cruft? The storage scales back down. Aurora splits out the compute and storage layers; that's its secret sauce. At an extremely basic level, this is no different from, for example, using a Ceph block device as your DB's volume. However, AWS has also rewritten the DB storage code (both MySQL/InnoDB and Postgres). InnoDB has a doublewrite buffer, redo log, and undo log. Postgres has a WAL. Aurora replaces all of this [1] with something they call a hot log. Writes enter an in-memory queue, and are then durably committed to the hot log, before other asynchronous actions take place. Once 4/6 storage nodes (which are split across 3 AZs) have ACK'd hot log commit, the write is considered persisted. This is all well and good, but now you've added additional inter-process latency and network latency to the performance overhead. Additionally, the storage scaling I mentioned brings with it its own performance implications. If you're doing a lot of writes, you'll encounter periodic performance hits as the Aurora engine allocates new chunks of storage. Finally, even for reads, I do not believe their stated benchmarks. I say this because I have done my own testing with both MySQL and Postgres, and in every case, RDS matched or beat (usually the latter) Aurora's performance. These tests were fairly rigorous, with carefully tuned instances, identical workloads, realistic schema and queries, etc. For cases where pages have to be read from disk, I understand the reason – the additional network latency of the Aurora storage engine seems to be higher than that of EBS. I do not understand why a fully-cached read should take longer, though. As a further test, I threw in my quite ancient Dell servers (circa 2012) for the same tests. The DB backing disk was on NVMe over Ceph via Mellanox, so theoretical speeds _should_ be somewhat similar to EBS, albeit of course with less latency since everything is in a single rack. My ancient hardware blew Aurora out of the water every single time, and beat or matched RDS (using the latest Intel instance type) almost every time. [0]: Arguably, it's also better at globally distributed DB clusters with loose consistency requirements, because it supports write forwarding. A read replica in ap-southeast-1 can accept writes from apps running there, forward them to the primary in us-east-1, and your app can operate as though the write has been durably committed even though the packets haven't even finished making it across the ocean yet. If and only if your app can deal with this loosened consistency, you can dramatically improve performance for distant regions. [1]: https://d1.awsstatic.com/events/reinvent/2019/REPEAT_Amazon_Aurora_storage_demystified_How_it_all_works_DAT309-R.pdf https://d1.awsstatic.com/events/reinvent/2019/REPEAT_Amazon_...

canadiantim 2y ago

People still use heroku?

eranation 2y ago

Happy Aurora Postgres serverless customer here. Be sure to use pgbouncer (self hosted, but it needs minimal babysitting) if you intend to use it in a serverless environment (and even if you are not, the benefits of not having to worry about connection pool exhaustion are still worth it). AWS's proxy won't work too well with prepared statements connection pooling (something known as connection pinning). EDIT: and yes, it's not cheap

olau 2y ago

A warning about Aurora: It's opaque tech. I've been on a project that switched to it by recommendation by the hosting provider, and had to switch away because it turns out that it does not support queries requiring temporary storage, i.e. queries exceeding the memory of the instances. It manifested the way that the Aurora instances would use up their available (meagre) memory, then start thrashing, taking everything down. Apparently the instances did not have access to any temporary local storage. There was no way to fix that, and it took some time to understand. After having read all the little material I could find on Aurora, my personal conclusion is that Aurora is perhaps best thought of as a big hack. I think it's likely there are more gotchas like that. We moved the database back to a simple VM on SSD, and Postgres handled everything just fine.

orf 2y ago
The first result on Google shows that Aurora certainly does have temporary local storage https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
- alexey-salmin 2y ago
  I believe this issue is (or was) real. There are important differences in how Aurora treats temporary data. Normal postgres and rds postgres write it into the main data volume (unless configured otherwise). Aurora however always separates shared storage from local storage and it's not entirely clear to me what is this local storage physically for non-read-optimized instance types. The only way to increase it is to increase the instance size. [1][2] This is indeed frustrating because with postgres or rds postgres you just increase the volume and that's it. Luckily since November 2023 it also has r6gd/r6id classes with local NVMEs for temp files. [3] This should in theory solve this problem but I haven't tried it yet. [1] https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.TroubleshootingStorage.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide... [2] https://www.reddit.com/r/aws/s/sIhBQhsG80 https://www.reddit.com/r/aws/s/sIhBQhsG80 [3] https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-aurora-postgresql-optimized-reads/ https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-au...

bingemaker 2y ago

After Heroku pulled their stunt in India when RBI changed some credit card rules, Heroku is pretty much history for me. They screwed small customers got rid of them saying they can't charge credit cards with new regulations. However they continued to entertain large customers from India. Never recommending them to anyone anymore

holografix 2y ago
You severely underestimate what a clusterfuck of credit card abuse comes out of India. Heroku used to lose millions a year.
- bingemaker 2y ago
  Care to shed some more light?
doutatsu 2y ago
Same - I've been slowly migrating to Render (https://render.com https://render.com) as my new favourite.

gregorvand 2y ago

Can you still see all instances with their IDs on a shared cluster when you connect?

tbarbugli 2y ago

RDS is such a depressing database option. It does not matter how much money you throw at it, its performance will always be limited by the awful disk IOPS. Luckily these days you can easily run PG on EC2 (or simply use CRDB). Weird for Heroku to ignore this huge efficiency opportunity.

p0seidon 2y ago
Have you tried io2 in this context? Did not have the chance yet.
- tbarbugli 2y ago
  io2 is generally better than io1, one advantage is that you can scale storage size and IOPS independently. That being said, RDS with io2 is still worse than an ec2 instance with nvme (a lot worse)
  - p0seidon 2y ago
    Yes agree every bare metal server probably beats EBS but a lot of manual work needed then.

breadwinner 2y ago

Google has 2 Postgres implementations: Cloud SQL and AlloyDB. How do they compare against AWS Aurora, for the heroku scenario, i.e., multi-tenant database?

PeterZaitsev 2y ago

Ah, I wish they would rather choose Neon... to get all the cool functions developers need but avoid going all the way proprietary.

nikita 2y ago

(CEO of Neon.tech) Aurora is one of the few real innovations in the database space recognized by SIGMOD: https://sigmod.org/sigmod-awards/citations/2019-sigmod-systems-award/ https://sigmod.org/sigmod-awards/citations/2019-sigmod-syste... It provides a lot of benefits to the user and also a ton more to the service provider. Specifically you don’t overprovision storage or compute. Plus at least theoretically you can provide invite IO throughput at the storage level. There has been a couple more iterations on the design since. Microsoft separated transaction log from storage: https://www.microsoft.com/en-us/research/uploads/prod/2019/05/socrates.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0... Neon added an object store and branches so you can integrate backups and add a Time Machine. PolarDB separated memory from compute - this makes serverless compute more nimble and unties memory and CPU.

richardgill88 2y ago

We're building on top of Aurora at https://xata.io https://xata.io. Currently our Aurora instances are in private beta. If you're interested in trying it out, drop me an email: richard@xata.io

ElectricBoogie 2y ago

[flagged]