> You can spin up a Postgres database, or a whole cluster, with just a couple of commands. Sign up for Fly.io and launch a full-stack app in minutes!
What is the HackerNews opinion on: who is their actual customer?
Obviously lots of companies pay for managed databases. It's not an uncrowded market for a reason.
But like... pricing wise... it seems so expensive? What is the HackerNews take on the valuable proposition specifically for hosted databases? Is the answer basically 1:1 with anything cloud hosting related?
Using Stolon for PG is a poor choice. Up until just very recently, they haven't had any significant updates in a year. We've abandoned our use of it in favor of EnterpriseDB.
> we’re good at consul
Thank god someone is. I’ve lost more of my life to consul partition failures that’s any other part of the nutech stack.
I always enjoy Fly.io's blog posts; the friendly, casual tone coupled with real-world experience and strong technical chops of the staff add up to HN gold in my book. I'll def revisit their "treat pg as an app" approach next time I engage w stuff in that realm.
I do have a question about this – (as I've said in another comment here) after investing a lot in building our own terraform/aws stack, we've started moving all our smaller apps to fly and it's downright delightful to the point where we are considering moving even our HIPAA-compliant software to Fly as soon as I saw the BAA option in your pricing, (and the only hesitation is that there is no Vanta integration and we'd probably have to fill out a bunch of stuff manually to make auditors happy).
But to my actual question: I remember seeing somewhere that Fly Postgres is not a managed database and isn't as fire-and-forget (somewhere in the docs), and that honestly scares me a bit. It shouldn't, because at the end of the day, RDS is probably downright hairy and ugly under the hood, it's just hidden from us.
I've also seen a handful of reliability issues on the forums around postgres. So what is Fly's position on actually running these clusters? Are you guys feeling pretty good about its stability for critical workloads?
On a related note, these folks that are continuing to use RDS via fly... what are the latencies like with a us-east-1 RDS? I know you're in Ashburn so it must be sub 5ms?
That itself would be worth keeping our RDS and moving everything else to Fly to be honest.
Improving Postgres is solid and boring.
Solid and boring is often a good choice. I'm glad to see startups in this space.
What's the latest on adoption of Spanner-like databases?
Never used Stolon, but I've hand good experience using Patroni to auto-manage the fail-over of multiple PostgreSQL clusters.
This is tangential - anybody have a reasonably clean way of running JVM apps on fly?
Given that the deploy model of a jettified jar is so clean in comparison to the various hipster stacks ;) that they do have primary support for, I'm not sure why they don't have much in the way of documentation for it. I did find a support thread that refers to https://archive.is/o9YE1, which seems like a fairly gross and opaque sequence of steps.
@tptacek, what are the chances that somebody at Fly could produce a more streamlined recipe and/or documentation for JVM apps?
Any way to run Fly with multiple locations at the same time? For context, I want to build a simple uptime service which tells me when my website is down, but for that I don't want to use a single VPS, I want to load balance between several locations and servers in case any one of them goes down.
Am I supposed to be looking for serverless deployment? Deploy a master/parent version of the app on one main VPS then several sub versions on other VPSes distributed around?
I have a somewhat unusual use case: A publicly available Postgres server with PostGIS for (infrequent) use with QGis.
I understand why Fly doesn't want customers to expose the database to the rest of the internet (ecosystem and such), but am very happy that Railway allows it.
Fly is pretty cool whilst free.
Very easy to setup stuff. Would recommend using prepaid credits because there's no capped billing.
Getting closer and closer to heroku deploy and auto config handles everything.
We are actually migrating from Fly because of bad performance and unreliability on the pg services.
Still love the company tho but can’t support it more :/
the site is down now
Database is a thing I never want to deal with at such low level. Such approach will be brittle, very brittle. Managed data storage with SLA guarantees is not easy and there are quite a few companies specializing on that for a reason.
As a proof, check out fly.io forums. They are full with posts about suddenly broken Postgres instances.