Skip to content

Comment on How We Built Fly Postgresparent

Comments

I was recently just one of those affected by a random issue! I was made aware in the forums that maybe my VM had run out of space. That would've helped if an error message immediately alerted to my exhausted disk space. I realized that what I actually wanted was a managed provider and moved (back) to Heroku just for postgres. I recently moved out of there for my backend hosting & postgres to fly.io. My backend hosting stays on fly.io but will be putting my postgres in a managed platform.

Just to be clear, your code makes postgresql connections from fly's servers to heroku's servers, I'm a little surprised. I'm not a web programmer, more of a traditional systems programmer, I have some questions.

I assume you use SSL, and these are not made on demand (connection pooling ?) On 'cold start' do you get massive latency ?

What kind of latency is there between client and server ?

What made you choose Heroku and not a specific managed postgresql service ?

Did you try flys postgres service?

Did you try flys postgres service?

Yes. I wrote: "I was recently just one of those affected by a random issue!"

I don't notice any measurable latency. Heroku exposes their postgres instances directly on the public web (secured with a strong user/pass combo of course), so there's no difference, networking-wise. There's no additional reverse proxy or some tunnel to route through.

Heroku was the cheapest for the very small instance I needed.

The connections are made on-demand and are insanely fast.

Thanks for the answers I'm going to look into this method.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.