People like us (Fly.io) will end up either building very mediocre DB offerings or collaborating with DB companies (like yours: https://www.crunchydata.com/products/crunchy-bridge/) to ship stuff that's substantially better than RDS. I'm looking forward to it. Down with mediocre DB services.
It turns out running a PaaS is a lot of work. Running a DBaaS is also a lot of work. If you've ever dealt with database corruption, it's not the thing you can just hand wave and do the same way across all databases, you need deep expertise in it, that or you say it's not my problem and offer a poor customer experience. Personally feels like we can do better in service quality as platform/database providers so doing one thing really well feels like a good direction to head for a bit (at least that's heavily what we're betting on at Crunchy Data by just focusing deeply and purely on Postgres).
- We give you full Postgres super user access, so less restrictions
- Quality of support, whether it's the Postgres basics of indexing or you've found a crazy bug deep in Postgres. Our team contributes a lot to upstream Postgres itself and can go as deep as we need to, but in general quality of support is a big differentiator for us
- We've been able to beat in cases price to performance just on the mix of Postgres experience coupled with our experience running on AWS/other clouds.
- Not locked into a single cloud, can go from AWS to Azure and vice versa with click of a button.
There's more details, and more coming particularly around the developer experience and proactively improving your database for you. But that's the high level pitch.
We'll likely have something in our docs (https://docs.crunchybridge.com) soon to address it more directly.
Good enough may be absolutely fine for a lot of people, but no lock-in to a single cloud, better developer tooling, proactive alerts and recommendations, quality support all feel like an opportunity to be better.
Kurt may have entirely other things in mind, and would be all ears if there is low hanging fruit in terms of feature or experience we can do to make Postgres even better for folks.
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.
This sounds great! How does it work though? Is it using some special postgres feature or btrfs snapshots or something else completely?
- restore from the latest snapshot (there was one whether you’d configured a custom backup schedule or not)
- replay the write ahead log over the top to catch the restore up to the point in time you asked for/when you ran the command. At least some part of this process leveraged WAL-E, which was a tool largely developed by Heroku employees and open sourced.
This was a decade or more ago though. The state of the art of postgres has moved on and I assume the team would tackle it differently if they were doing it today.
Doing the native approach in Postgres isn't perfect, but we've focused on getting the developer experience for it down so you can use your database and it "just work" and if something goes wrong you understand how to rollback seamlessly.
The good DBaaS give me a lot more power. This is true for Heroku PG, PlanetScale, Supabase, and Crunchy Data. Some of them let me fork a DB to run a PR against, some give me app level features that save me code, etc.
Most modern hosted DBs also let you run your own replicas.
I'm not really complaining about how well RDS works when your app is connected to it and it doesn't failover/go down for maintenance/etc. It works fine as a DB backend. That's just a baseline I don't think is very valuable anymore.
no affiliation. just a customer.
at the time we picked aiven, we couldn’t find any redis-specialized hosting with instances in GCP europe if I recall. so their breadth also plays in terms of locating near the customer servers (important for latency)
RDS makes it very inconvenient to do anything other than use their managed services.
because RDS backup data storage is VERY EXPENSIVE even compared to s3. this is very deliberate.
Anyone else have any idea if there's a better option??
My current strategy is to use Heroku to test waters, If the validation is successful then migrate to fly.io.
Sad to see that momentum eventually fade away.
Do they actually have responsibilities in their role or is it more just to slap the branding on to them while they continue to do their own thing, whatever it may be? (in Matz case I would think he has more than enough full time work on Ruby itself)
Also while I have you, do you support deploying to Canadian regions?
Thanks!
We don't have a Canadian region yet, but we'll get there!
It sounds prosaic but "it just works".
Specifically compared to Digital Ocean Apps (which I used before render):
* the dashboard UI is better designed and faster
* the builds and deployments happen faster
* similar price (to Digital Ocean, much cheaper than Heroku)
* similar capabilities (attached disks, hosted Postgres, hosted redis) but the velocity seems better i.e. render.com seems to implement features faster than DO
You would think that "well designed dashboard that displays instantly" would be a table stakes in an offering like that, but sadly it isn't.
I mean if this is how you're going to treat your customers, then good luck! I'm yet to try out railway.app and..looks interesting to say the least.
Uhhh... I don't think that's true. There were 3rd party buildpacks available.
At the time of acquisiton (Dec 2010) the Bamboo stack was the only GA stack, Cedar was in beta which used buildpacks internally but custom buildpacks didn't come to 2012 https://blog.heroku.com/buildpacks
Some examples of innovation that happened and were launched after the acquisition: buildpacks (at the time of acquisition Heroku was still Ruby only), Heroku Postgres launched forks/followers/dataclips all after the acquisition, review apps came several years after. Salesforce may have had an eventual hand in it, but there was still a lot of innovation happening due to the folks there in the near to mid-term after the acquisition for several years.
All that said, very excited for the new crop of players in the space. There are a number of companies trying to be a cheaper or more stable Heroku. Personally I'm excited about the ones that are taking their own unique approach. https://www.fly.io and https://www.railway.app are two that to me seem to bring their own perspective vs. just trying to recreate Heroku as a carbon copy clone. There are a number more in the jamstack space that have become staples such as Netlify and Vercel which are also doing great things.