![]() ![]() You can deploy two Postgres VMs configured so one’s a writable leader and the other is a standby replica staying up to date by asynchronous streaming replication. Postgres has a lot of levers and buttons built right in. Then you have what you can call a high-availability (HA) cluster. And if the leader goes down, you want that replica to take over automatically. Here’s a better setup: one primary, or leader, instance that deals with all the requests, and one replica instance nearby (but preferably on different hardware!) that stays quietly up to date with the latest transactions. If anything happens to your lonely node, though, your Postgres service-and so, your app-is down (and you may have lost data). If you’ll only ever want this one instance, this is pretty good. (Then fly ssh in and create a database and user for your app.) ![]() Remove the default services in fly.toml, since this isn’t a public app. Here’s a way you can run Postgres on Fly.io: point fly launch at the latest official Postgres Docker image. Everything still holds it’s just more and better now. This post is mostly ancient history! Shaun’s no longer a team of one, and lots has happened since this post should have been written and shipped. When Shaun arrived at Fly.io later that year, he took over the job of making Fly Postgres more reliable and more convenient to manage-still in hard mode: developing and shipping features that make the platform better for apps like Fly Postgres, and making Fly Postgres plug into those. (The alerts were as cursed as our shared Redis.) This was a big-deal effort for us. In January 2021, we soft-launched a fly pg create command that would deploy an automagically configured two-node Postgres cluster complete with metrics, health checks, and alerts. It’s familiar and just works with the migration tools baked into full-stack frameworks. ![]() So we devised a cunning plan: Build the platform out so it can run a database app, build a friendly database app for customers to deploy on it, and add some convenience commands to deploy and manage the app. Storage capabilities or not, we still didn’t want to be in the business of replicating all of RDS. Now, disk storage is just one of the puzzle pieces for giving apps a reliable backing store. ![]() RDS! Feh! Somewhere around then, Jerome and Steve figured out LVM2, gave all our apps attached disk storage, and killed off the stateless platform talking point. What did we want to spend our time building? Another RDS, or the best platform ever for you to run stuff close to your users?īy day two hundred and ninety or so, the appeal of articulating and re-articulating the logic of a stateless global platform for stateful global apps began to wear off. Hooking globally distributed applications up to RDS was (and remains) something ordinary teams do all the time. Rather, they just needed to use off-platform database services, like RDS, CrunchyData, or PlanetScale. Here’s our 2020 reasoning, for posterity: just because we didn’t offer durable storage on the platform didn’t mean that apps running on Fly.io needed to be stateless. We even toyed with the idea of offering a managed CockroachDB like us, Cockroach is designed to run globally distributed.Īnd then we snapped out of it. We rolled out an (ultimately cursed) shared Redis. We flirted with the idea of investing in a platform built-in database. Somewhere around day fifteen, we grew out of the idea of building a platform exclusively for edge apps, and started looking for ways to get whole big crazy things running on Fly.io. But, on days one through three hundred thirty-one, we held the line. Of course, people asked for databases from day one. In an “edge app” world, not having durable storage makes some sense: the real data store is in us-east-1, and the slices are chosen carefully to speed the whole app up (by caching, running an ML model, caching, serving images, and caching). We were a platform for “edge apps”, which is the very 2019 notion of carving slices off of big applications, leaving the bulk running in Northern Virginia, and running the slices on small machines all around the world. We started Fly.io without durable storage. So we thought we’d take a few minutes to lay out where we’re coming from with databases. When we relate this in conversations online, people are often surprised. The reasons for that are interesting, as is the way Fly Postgres works. Sign up for Fly.io and launch a full-stack app in minutes!įly.io is an ambivalent database provider-one might even use the word “reluctant”. You can spin up a Postgres database, or a whole cluster, with just a couple of commands. Where AWS has RDS, and Heroku has Heroku Postgres, Fly.io has Fly Postgres. Like many public cloud platforms, Fly.io has a database offering. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |