Earlier quoted context omitted.
I'm curious about what "substantially better than RDS" means. RDS has been good enough for me for quite a while. Does it only matter once you get to a certain scale?
Craig here from Crunchy the company he's referring to. Not sure what he has in mind, but having built a lot of Heroku Postgres in the early days I definitely have thoughts on what can make a database great. There is a big gap between most developers and what you need to know to efficiently run Postgres. Without tipping too much of our hand, we're focused deeply on building an amazing developer experience for Postgres…
Some examples of the things I've missed around developer experience for a database, that Craig and the team made possible at Heroku Postgres, include:
- fork: ever had one of those "why does this bug only exist in production?" problems? It was so trivial to fork the DB and run your tests/hypothesis/whatever without the risk of actually impacting production. Same thing for _really_ testing a migration script or load test.
- follow: a similarly easy approach for getting a read replica which is super useful for generating reporting.
- dataclips: "hey, can you tell me X?" sure, and here's a URL to the results that you can refresh if you need an updated number in the future. So great for adhoc queries.
All of these are obviously doable with RDS and/or other solutions too. But the time taken to do any of the above was often measured in seconds, at most minutes. It's difficult to communicate just how impactful those kind of improvements are to your workflow. It's like it subconsciously gives you permission to tackle whole new problems, build better solutions, get answers to questions you never thought to ask before. Because the barrier to entry is so low you just do these things. You don't sit around wondering if you could.
A great developer experience around a database (one that goes beyond setup and basic ops) is a severely under appreciated thing IMO.