Cloud hosting: databases

The classical way for running a database has always been very simple: you run your webserver and it hosts something like a LAMP stack, with the “M” being MySQL - you can substitute this with Postgres, MariaDB or basically any other database system.

The idea is simple: you run one VM which runs all the services necessary for your project. And to be fair: capacity wise this is perfectly fine for most small projects. You can use a service like Laravel Forge or any of the hosting and webserver management panels out there to help you with provisioning and be fine in many ways.

Where the picture shifts for me a bit is once you're running a business and the data in that database actually becomes one of your most valuable assets. webservers or workers can easily be replaced with the code being pulled from version control again, cache servers are ephemeral anyways and uploaded files we get from our users can be stored safely in S3. I have also had to deal with some practical downsides of running my own databases: having to manage backups, being responsible to restore from those backups after a server stopped working, upgrading servers to the newest OS version with a new version of MariaDB and running into issues because a default config value changed.

Unsurprisingly after my shift on hosting email services: here as well I have come to embrace managed offerings more. I still run my own databases for side projects or just dev versions - but I'm leaning a lot more to managed options when it comes to production apps. With PlanetScale, Neon and AWS RDS we have good options available for all common database types. Generally it seems that on the lower end - in terms of price - the offerings for Postgres are a bit more numerous (Neon with their free tier, PlanetScale with the 5€ per month tier) but even for mysql/mariadb the offerings are good.

Now but what exactly does all this give me? Two things: responsibility for operating database servers rests with a product built by database experts with more experience than I have or smaller teams will reasonable have available. And the second: features that would normally require a lot of that expertise. Setting up replication with automatic failovers requires some knowledge, making sure that a new replica is now spun up and ready to go even more so. This would simply not be available as a small team focussed on actually building products - or put differently: these features become available from the start and not after reaching significant scale and then having to go through migrating to new infrastructure.

So what’s the takeaway? Just like with transactional emails, the value isn't about scale—it's about reliability and focus. If you are in a position where the data in your database (or reliably running an application that relies on it) represents a significant value you should take a look at the providers mentioned here (and I’m sure there are more great ones out there). It’s not just something for large enterprises or hyper growth startups.