Preview: Postgres on Machines ( Fly Apps V2 )

1

Hey everyone,

We would like to offer a preview of our new Postgres offering built on top of Fly Machines. This preview represents our first big, visible step towards Fly Apps V2.

Fly Apps V2 is our next-gen architecture built on top of Machines. Fly Apps V1 is our current architecture orchestrated by Nomad.

I would like to re-emphasis that this is a preview and that there are some known rough edges that we are actively working through. This should not be used in production quite yet.

Getting started
Make sure you are running the latest version of flyctl and issue the following command:

fly postgres create --machines

For documentation, head over to: Fly Postgres · Fly Docs

A Few Noteworthy Highlights

Built-on Machines
Read more about Fly Machines here: Machines · Fly Docs

Flyctl specific documentation is coming soon!

Communication
Fly Apps V2 offers a more direct-line of communication with individual VM’s. This will allows updates, restarts, etc. to be issued to given VM without having to interact with our centralized API. This will provide a much better experience for everyone, but especially to those of you operating outside of the U.S…

Orchestration
Orchestration has gotten substantially more flexible and can now be managed through our Machines API. This has allowed us to make significant improvements to our Postgres tooling and has introduced exciting new opportunities for client side orchestration. In fact, all of our Postgres on Machines orchestration is now managed by flyctl.

Feedback

Please let us know what you think and please report any issues you may come across. Also, feel free to send over any questions you may have!

5 Likes
2

Thanks. I have a feedback on V2.

Right now, it seems as if the proxy wakes up Machines for just a single connection (and sometimes, for no connection!). Fly could be way more smarter in how it starts new Machines, preferably sending the traffic to a single VM until soft_limit is hit. I don’t observe that happening in the current setup, like at all.

Such behaviour surprised me, given Kurt once explained the proxy is really just a very simple affinity-based load-balancer. I’ve got 40+ Machines, with 3 Machines in some regions. In those regions, I see all 3 Machines start up to serve mere 3 requests per minute each, when in reality, the soft_limit of 175 should have meant just one Machine was ideally spun up, instead of 3.

When is V2 expected to be prod ready (I’m thinking 7 to 9 months)? I’m already planning my move over to Machines as it is infinitely better to work with than autoscale.

Neat!

1 Like
3

When is V2 expected to be prod ready (I’m thinking 7 to 9 months)?

I don’t have any good estimates for you quite yet. It’s something we are pushing towards, but we still have a decent amount of ground to cover.

Postgres on V2 is our first big step in that direction.

2 Likes