Heroku Postgres is now based on AWS Aurora

https://blog.heroku.com/heroku-postgres-essential-launch

by mebcitto • 2 years ago

211 142 2 years ago

blog.heroku.com

metadat• 2 years 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• 2 years ago

That's 750$/month now, I think: https://elements.heroku.com/addons/heroku-postgresql#pricing (Standard 4)

SahAssar• 2 years 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• 2 years 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_peterson2• 2 years 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

vips7L6• 2 years ago

Why did I think you were leading the Apex product team?

mebcitto• 2 years 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• 2 years ago

Oroboros eating its tail

muratsu2• 2 years 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• 2 years 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

muratsu2• 2 years ago

Vercel is going strong - 25.5M in 2022, 100M in 2024. Netlify is currently at 30M. Add Supabase, Render, Railway, ...

teaearlgraycold5• 2 years 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.

iancarroll5• 2 years 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• 2 years ago

Aurora has a new configuration option that changes billing from iops to higher storage costs. Might be what this is using.

iancarroll5• 2 years 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.

drusepth• 2 years 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.

iancarroll5• 2 years ago

I am not seeing the margins in this $5/mo instance but I could be wrong!

chuckadams• 2 years ago

Just curious, does Aurora scale down at all in price, i.e. if I have a test instance that's hardly ever used, does it ever end up being cheaper than a classic RDS instance?

nilamo• 2 years ago

It scales to zero, so costs nothing when it's not in use...

tudorg• 2 years ago

Disclaimer: I work at xata.

Xata is (like Heroku) based on Aurora, but offers database branching and has different pricing. That should be ideal for lightly-used test instances, because you only pay for storage, and 15GB are included in the free tier.

andrewstuart• 2 years ago

> Aurora isn't cheap and is at least ~80% of our monthly AWS bill.

Why don't you run your own Postgres?

It's not hard - why pay such a premium for the Amazon version?

szundi• 2 years ago

Is it less true for other cloud stuff?

teaearlgraycold5• 2 years ago

If you’re using Aurora and not RDS you’re probably outside of the zone where rolling your own Postgres is easy.

williamdclt• 2 years ago

“Not hard” is very relative. Is it hard to run a Postgres database? No. Is it hard to set up monitoring, automatic failover (without data loss), managed upgrades, tx wraparound protection, clustering and endpoint management, load balancing… and probably a bunch of other things I’m not thinking of? Yes.

dalyons6• 2 years ago

You clearly don’t know what aurora is or does if you think people can just run their own. It’s not a regular Postgres setup, and nothing exists that’s equivalent for self hosted.

jrockway• 2 years ago

Aurora has treated us well. We make a self-hosted product that requires Postgres; our sales/customer engineering folks just started telling people to use Aurora, and it hasn't caused any problems despite the fact that all of our tests run against stock Postgres. Can't complain. Though a VM with Postgres would be plenty for our needs, and cost thousands of dollars less a month. But, HA is nice if you want to pay for it.

alexey-salmin3• 2 years ago

Try the Aurora IO-optimized, it's a (relatively new) game changer price-wise.

I'm migrating a 1tb database to it right now because I'm paying too much for iops even on the regular rds postgres.

I'm also quite sure this is what heroku must be using or they would be out of business because of the pricing mismatch.

dangoodmanUT2• 2 years ago

This, Aurora normal is useless now

p0seidon4• 2 years ago

How much do you expect the price to drop?

Scubabear68• 2 years ago

Came here to say this. Aurora is good but also very expensive. If your queries are not very well tuned you will pay through the nose for I/O that would be unnoticeable in other Postgres implementations. For a very modest installation I saw DB bills go down from $3,000 a month on Aurora to about $100 for self managed Postgres.

rnts082• 2 years ago

Everything on Heroku is billed with a huge margin, plus as they're probably a partnered customer by now their pricing is a fraction of the average AWS customers pricing. I've been at companies on both sides of the partner pricing list and the difference is huge.

dangoodmanUT2• 2 years ago

Use io optimized

colesantiago• 2 years 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.

risyachka• 2 years 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

Andugal• 2 years ago

For a lot of use cases, nothing beats « git push » and tada your app is deployed.

zdragnar• 2 years 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.

csjh• 2 years ago

That’s a pretty standard feature nowadays

davepeck3• 2 years 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.

fellowniusmonk• 2 years ago

I revisit heroku alts every ~6months and I am shocked how not ergonomic they still are, I switched to DO VPS + Ansible Container & Github Actions for any project that doesn't need infinite scale after Salesforce paused heroku development but I'd go back to literally any heroku clone.

It's crazy how the ergonomic still just aren't there.

strix_varius• 2 years ago

IME the Heroku of 2024 is Render.

swader999• 2 years ago

It's really easy to be SOC2 compliant for a small SaaS on heroku. We need to grow in customers and Dev resources to pull it off on Raw AWS. Am looking for options though because heroku is increasing their prices.

teaearlgraycold5• 2 years ago

I use render.com. Heroku is stuck in the past.

karmelapple4• 2 years ago

We do, although we're in the middle of moving our entire Heroku Postgres spend over to Crunchy Data [1].

We were getting close to one of the big jumps on the standard pricing of Heroku Postgres, and we would have had to basically double our monthly cost to lift the max data we could store from 1.5TB to 2.0TB. On Crunchy Data, that additional disk space will be like 1% more rather than 100% more.

While investigating Crunchy, I ran some benchmarks, and I found Crunchy Bridge Postgres to be running 3X faster than Heroku Postgres.

Heroku seems to be working on some interesting new things, but I feel burned by the subpar performance and lack of basically any new features over many years. I don't know if the new Aurora-based database will be faster than Crunchy, but the benchmarks they're talking about sound like they're finally about to catch them. But we also have better features on Crunchy, too, such as logical replication. Logical replication is still not available on Heroku.

The experience for deploying apps and having add-ons is still pretty easy, but we'll see how that improves. HTTP2 support is still in beta.

1. https://www.crunchydata.com

singingfish• 2 years ago

+1 - recommend crunchy. I ran a substantial oracle to postgres project recently and crunchy were great.

cyberax• 2 years ago

I'm working in a new startup, and I tried several "easy" solutions: AWS Lightsail, Heroku, Crunchy.

I settled up on AWS ECS :)

My main issue with Heroku was that they have not changed anything in _years_. No support for gRPC, no IPv6, and simple VPC peering costs $1200 a month.

almost2• 2 years ago

My experience with going from Heroku Postgres to Crunchy Data (specific Crunchy Bridge) has been really good. Their product has been absolutely rock solid but what really made the difference was their support. They provided a huge amount of pre-sales support while I planned the move (and even suggested mitigations for the problems I was having with Heroku Postgres to make moving less urgent). Post-sales support has been just as good, though mostly I don’t even have to think about the database hosting anymore.

I also moved my app hosting to NorthFlank from Heroku and have been really happy with that as well. It’s got the features I always wanted on Heroku (simple things like grouping different types of instances together into projects really helps) plus again excellent responsive support.

karmelapple4• 2 years ago

Update to this: we've switched over our staging database, and the call to do that couldn't have been. more productive or more pleasant.

I got to talk to someone who was intelligent about Postgres, who answered various questions I had, who offered a few pieces of insight that I wouldn't have thought, etc.

Compared to every single support interaction I've ever had with Heroku for 10 years, and this was light years more friendly, informative, and productive.

I am so happy we're switching. Way to go Crunchy!

cakoose• 2 years ago

A few years ago I was considering Heroku for something new. But then I learned that Heroku Postgres's HA offering used async replication, meaning you could lose minutes of writes in the event that the primary instance failed. That was a dealbreaker.

That was very surprising to me. Most businesses that are willing to pay 2x for an HA database are probably NOT likely to be ok with that kind of data loss risk.

(AWS and GCP's HA database offerings use synchronous replication.)

hot_gril2• 2 years ago

Noticed this too. The master failover is marketed like a strict upgrade, and the "async" part is only in the fine print. Many would actually prefer the downtime over losing data. A user who's experienced with DBs should think to check on this, but still.

WD-42• 2 years ago

VPS is dandy when the application is fresh. Once it starts getting long in the tooth and the VPS OS needs to be updated… nightmare fuel.

hot_gril2• 2 years ago

Me. Haven't found anything that's just as easy to use. The supposed Heroku replacements like Fly.io weren't.

greenie_beans3• 2 years ago

me. tried to move to render but it's been a headache for some key things that i need. my heroku setup is dialed in so it makes it a no brainer versus the time i've wasted trying to get render to fit my use case. right now i'm using both for two different services, and will consider moving off both once i get enough customers.

anurag• 2 years ago

What are you trying to do on Render? We have some stuff in the works and I'd love to find a way to help.

bvirb• 2 years ago

10yo+ B2B SaaS company we're still on Heroku. I think the value prop is particularly good for B2B SaaS and probably less so for consumer products. Our margin per customer is so much higher than the infra cost it just never makes sense to spend money on devops instead of building features.

That said it does feel a bit like a ghost town, I'm always happy to hear when someone is doing something over there.

toasterlovin2• 2 years ago

I’ll just share our experience with Hetzner from earlier this week to spare everyone the learning experience. Their prices are indeed incredible. However, we spun up a VPS in their Hillsboro, OR data center only to find out that our IP address was blocked by Cloud Flare, so there was no way for us to connect to our error logging or transactional email providers. We also found this thread indicating that their entire IP range for that DC is widely blocked[0]. So, not really acceptable for professional use, IMO, unless you just need compute.

0: https://news.ycombinator.com/item?id=39638849

sammy22552• 2 years ago

Cloudflare doesn’t block any ip addresses. Its their customers that do

sammy22552• 2 years ago

Hetzner doesnt offer any SLAs which is important for some people

devoutsalsa• 2 years ago

Then you have to manage a VPS. If you want to do ops, you’re not Heroku’s target customer.

drewda• 2 years 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• 2 years ago

Which Postgres committers work at either of those companies?

hoomanmo• 2 years 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.

greenie_beans3• 2 years ago

Amplify is the worst!!!!

mattacular2• 2 years ago

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

sgarland7• 2 years 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• 2 years ago

What makes RDS better than Aurora?

mattacular2• 2 years ago

I'm not sure what you mean by "running your own on native NVMe" Are you talking about using the managed AWS Relational Database Service or something else? Aurora can also use instance types with NVMe.

Anyway, that's also ignoring the features that Aurora offers, which is why people pay more for it. The ability to have multi-AZ deployments and auto-scaling of (what can be cross-region) read replicas make it very resilient and it's dead simple to operate what would normally be considered advanced features of a DB cluster.

If you just need a managed Postgres or MySQL traditional single instance and none of those extra features, then obviously you would not need to pay the premium for Aurora. RDS exists for that reason.

eranation• 2 years 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

canadiantim• 2 years ago

People still use heroku?

olau• 2 years 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• 2 years ago

The first result on Google shows that Aurora certainly does have temporary local storage https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...

alexey-salmin3• 2 years 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...

[2] https://www.reddit.com/r/aws/s/sIhBQhsG80

[3] https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-au...

pquki4• 2 years ago

Isn't Aurora mainly about their unique handling of logging and replica which leads to high availability and fast recovery? If you switch to VM, how do you handle availability in multiple locations and backups? If database checkpoints are good enough for you, sounds like Aurora is overkill in the first place.

vips7L6• 2 years ago

We’re currently struggling with switching from RDS to aurora. The replica times are absolutely bonkers long for the simplest of writes.

alexey-salmin3• 2 years ago

Can you elaborate, which exact timings are bad?

dalyons6• 2 years ago

Aurora has essentially constant replica lag times, it’s one of the best features. Should be around 30-50ms always, are you seeing different?

dalyons6• 2 years ago

Calling it a hack is pretty unfair. The log storage engine is a huge innovation, in my experience makes large MySQL/pg clusters much more reliable and performant at scale in a variety of different ways.

It has a couple of quirks, but on balance it feels like the future - the next evolution of what traditional rdbms are capable of.

But if you don’t have scale or resiliency needs it probably doesn’t matter to you.

deergomoo• 2 years ago

We’ve generally been happy with Aurora, but we run into gotchas every so often that don’t seem to be documented anywhere and it’s very annoying.

Example: in normal MySQL, “RENAME TABLE x TO old_x, new_x TO x;” allows for atomically swapping out a table.

But since we moved to Aurora MySQL, we very occasionally get stuff land in the bug tracker with “table x does not exist”, suggesting this is not atomic in Aurora.

Is this documented anywhere? Not that I’ve been able to find. I’m fine with there being subtle differences, especially considering the crazy stuff they’re doing with the storage layer, but if you’re gonna sell it as “MySQL compatible” then please at least tell me the exceptions.

bingemaker2• 2 years 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• 2 years ago

You severely underestimate what a clusterfuck of credit card abuse comes out of India. Heroku used to lose millions a year.

bingemaker2• 2 years ago

Care to shed some more light?

doutatsu• 2 years ago

Same - I've been slowly migrating to Render (https://render.com) as my new favourite.

gregorvand• 2 years ago

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

tbarbugli2• 2 years 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.

p0seidon4• 2 years ago

Have you tried io2 in this context? Did not have the chance yet.

tbarbugli2• 2 years 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)

breadwinner• 2 years 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• 2 years 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• 2 years 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-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/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• 2 years ago

We're building on top of Aurora at 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

Heroku Postgres is now based on AWS Aurora

Related Stories