Fly Postgres, Managed by Supabase
supabase.com
supabase.com
Fly's current Postgres offering is unmanaged, so we're working with them to run their managed offering. This is the same model that they run with the Upstash team for Fly Redis[0]
We're still working with testers to roll out HA features. We don't have firm timelines yet unfortunately, but we'll work with the Fly team to make it happen as soon as possible
I'll stick around for any questions/comments
[0] Redis: https://fly.io/docs/reference/redis/
Supabase and Fly.io are awesome - can't wait to see how cool they can get together!
nice touch!
Oh, this must be genuine, hip CEO who has disabled autocapitalisation (or fought it) and not bothered to capitalise anything anyone else with similar education level would ... Until the next paragraph!
If I am ever in such a position and make such a decision I hereby give anyone and everyone permission to berate me and point me back to this comment and I'll correct myself thenceforth.
I don't even really follow your point. Surely if I am 'too prescriptive' in wanting proper capitalisation, that is .. not exactly inconsistent with a 'wordy' choice of word anyway?
I really hope this improves. I love what they are doing but there's a reason my company elected to build out a custon deployment on aws. reliability is KING when you have paying customers. Until they bring those numbers up, they are only going to be good for hobby projects
I vividly remember hanging out on my back porch with Kurt as we were plotting out attached storage (we didn't even start out with storage!) and him telling me how hard it would be to replicate the kind of work Craig and Paul had done --- he'd know, after doing Compose.io! We had no illusions that we were going to provide that.
Instead, we charted out a halfway point: "automated" but not "managed" Postgres, which is almost (not quite) just an application you deploy on top of Fly.io. You can see from my sibling comment how well that went. A managed database practice monitors and intervenes with database clusters in ways a fire-and-forget automated system doesn't. If you don't do all that work --- a whole (huge) company's worth of work --- you break peoples expectations, and they question your pedigree on message boards. :)
Supabase suggests you to use their DENO serverless functions which is cool and all but i think most people would rather deploy node functions on cloudflare for webprojects.
That being said the target customer group are those that want to have 99% of their logic in JS frontend. Backend just does CRUD and Auth.
We’ve decided to only bundle trusted language extensions so that there is a balance between flexibility when it comes to users writing their own procedures, all while maintaining security.
you have a few options:
1. connect to Postgres like you do with any other Postgres database. Supabase is just postgres
2. connect to PostgREST, the autogenerated REST API that you mention
3. connect using Edge Functions (Deno)
Most people are fine with 1. You can use 2 & 3 if you want to, they are just another tool in the shed
If your DB needs are simple then the REST api is very convenient. But if you are planning anything of complexity then you'll have to bone up on your PL/pgsql or go for a regular db connection instead.
In that sense, if you are like the business owner who swears by SQL and making the database the core business-logic layer of your system, then you might even appreciate that Postgrest forces you do move that kind of logic into the database. It is just something to be aware of before you make the decision so you that you aren't surprised when it happens.
We have a dashboard that displays aggregated stats for our admin users, and we hit serious performance issues with ~600 users with our first implementation. This repo helped us: https://github.com/GaryAustin1/RLS-Performance
This stuff is "really cool" but just keep in mind that it is pretty advanced. And exactly as another commenter noted in this thread, it is possible to destroy your performance if you need to join on other tables in an extended version of this kind of RLS policy.
In this repo, the logic is simply "if a claim exists on the JWT then grant access". But in a lot of cases you may want to do something like "if this user is an owner of <row in another table> then grant access". That can require a join to that other table. That logic can get even more complex, for example, you might want to say "allow the user access to this row if they are an owner of the project". So you have to do more work to join from a child table, to a project table, to the user table, etc.
These operations are in addition to any work you might be doing in the actual query that is executed. I have no idea if the query planner can recognize you are doing the same joins in the RLS as the main query and optimize that away. But at any rate, every single policy invocation (on every single query) will be executing this logic.
These are all considerations if you are planning more advanced access policies to your data. If all you need is a binary "can access"/"cannot access" then basic RLS policies may be fine. But once you get into even moderately complex scenarios your policies are likely to balloon in complexity and you'll be writing a fair amount of PL/pgsql and fighting with testing and validating.
1.https://github.com/supabase-community/supabase-custom-claims...
The bigger downside, IMO, is the dev experience. They are hard to debug and to test their performance. Of course, everyone has a different bar for what they consider "hard", but if I start getting back result sets from the db that don't match my expectations, or if the performance isn't what I expect, I have to track down if the culprit is my query, the RLS or some combination of those. And while I am pretty confident with SQL, I am not so confident in PL/pgsql - which was the point of my original comment. You will have to get confident in that if you go down this route. You'll have to learn what amounts to a complete language but you won't have logging, a debugger, etc. just a rudimentary set of tools.
I'm not telling people not to do it - just warning them that the path passes through some thorny territory and you may get scratched up. It isn't all roses.
I suppose I would like to have the problem of having so many users that my app begins to get bogged down, so I'll cross that bridge when I come to it.
The RLS stuff seems like a bonus that I can choose to use if I want to, and I was happy not having it before, so I'm planning to be careful about actually activating it in any projects going forward -- it would have to be a use-case that I thoroughly understand.
We handled that by having an event system built on the Postgres WAL that we use like a callback system.
I put together a little library in Elixir (that originally started out as forked Supabase realtime) for this:
https://github.com/cpursley/walex
Recently added the ability to configure WalEx to forward events to webhooks or EventRelay (so you don’t need to know Elixir).
Question for the team members here - will the new PG still have the same HAProxy in front?
[1] https://www.contraption.co/essays/booklet-architecture/
[2] https://community.fly.io/t/postgresql-connection-issues-have...
[0] https://supabase.com/blog/supavisor-postgres-connection-pool...
My second reaction was that it's crazy there's 'Postgres by Fly' and 'Postgres by Supabase' in the sidebar. There isn't even an (obvious, or that I noticed) comparison offered. If I'm deploying an app on Fly and want postgres, what do I use?
(Personally I think if I use Fly and want a dbms I'll use LiteFS distributed SQLite, and if you do want postgres I think the answer is that Fly vs Supabase is basically unmanaged vs. managed.)
If your expectations are set from Heroku's Postgres, you want a managed database. You're going to notice that Fly.io people aren't going to push you to Fly Postgres. You want to be reasonably comfortable with clustered Postgres to choose our unmanaged Postgres over Supabase's --- maybe not so comfortable that you'd set it up yourself (it's automated, after all, and does a bunch of cluster orchestration for you) --- but enough to do your own monitoring, sizing, and provisioning.
Lots and lots and lots of people rely on Fly Postgres, and it's a reasonable option. If I was doing a low-level project, like an individual service in a larger ensemble, or an expiriment or side project or a spike, I'd probably use Fly Postgres. But if I was launching a whole product on top of Fly.io, and a Postgres database was my system of record, I'd want Supabase.
I stand alone athwart all efforts to introduce dynamic routing protocols here.
(I could still lose this argument if there are comparably important use cases).
I've had a bit of experience implementing IGP-style routing --- both as a "user" (a Cisco network engineer doing multi-area OSPF) and a developer (of a custom link-state IGP) --- and it left me pretty terrified of the failure modes here, which feel pretty similar to those of Raft/Paxos consensus, or of the SWIM Gossip consensus we do in our Consul replacement, Corrosion, which has its own challenges. If there are "innovation tokens", there are also "distributed consensus" tokens, and my basic take is I don't think we should spend them for such a marginal feature.
Here I am litigating an internal company discussion on HN (this is simultaneously bad, and an exercise in us just being an open book). I remind you of the initial paragraph here, which lays out plainly that the people in our company who disagree with me are smarter than me. A really good use case could end my reign of static routing reign of terror!
Or one can push the other vendor to implement vpn support on their side such that their service can talk to Fly.io-hosted ones in an end-to-end secure channel so the actual services can trust that a lot more. This is the solution often suggested in Fly.io forums.
If the other vendor is sending ostensibly private traffic over the public internet and relying on a combination of “the Postgres protocol is safe and passwords are strong enough” and “oh but they really aren’t so we will limit this service to talk to only one IP address” it seems to me it’s them who should be nudged towards a more secure and versatile solution.
perhaps OP is talking about this[0] post, which is mostly about struggles with local development. we addressed this here[1]
here is an app this week that I imagine is larger than most: https://twitter.com/seif_ghezala/status/1734967554659983418
Do you have any details on pricing (for this new postgres offering) yet?
this will follow our current pricing: https://supabase.com/pricing
there could be some changes once we get through the testing phase and after Fly have blob storage, but they will probably be more favorable to you, the developer
---
Original comment:
Hmm... this seems to say 8GB storage, 250GB bandwidth and 7 day backups (not point in time) for $25/month? + 7 day point in time backups for an extra $100/month? But it doesn't seem to mention anything about the CPU or RAM specs of the database server? And it also seems to bundle a bunch of other things, so it's hard to know how much of that is for the database server...
Will it be possible to choose different sized servers? And to buy managed Postgres on it's own without running the whole of superbase?
Is bandwidth also paid considering it will be only used in the internal Fly network?
I've never used AWS, and I'm not too familiar with network-attached storages in general either. Can someone explain what's the exact difference between a Fly volume and a network-attached storage offered by other providers?
IIRC, once you create a Fly volume, you can move it to another server in the same region? So aren't they technically network-attached storages?
Under the hood, we can migrate a volume from one physical to another (the way we do this is pretty interesting and we'd write it up, except that to date the process has played an outsized role in the work sample testing we use for all of our technical roles). I don't think we've surfaced that, much, yet, but we will this year.
We back Fly Volumes up to off-network block storage at regular intervals (more announcements coming shortly here too).
But a really basic thing to understand about Fly Volumes is that they're not SAN storage, and they're not intrinsically reliable the way, say, S3 is. They appear in Fly Machines as simple ext4 filesystems, and if you need reliability/durability/replication, you need to provide it at the application layer. That's how Fly Postgres works: clusters of read replicas, all of which can take over and assume write leader role if they need to. This makes sense because with Fly Postgres the only purpose to which the underlying volume is put is running a Postgres database, which already provides durability/replication.
This is, for instance, why we print a big red warning on the console if you ask us to create a single-node Postgres cluster.
I think we're going to roll out stuff in the next couple quarters that will offer new options on the reliability/perf spectrum. But I don't think they'll involve us running SAN drives --- servers that just expose block devices over iSCSI or whatever.
Looking forward to more storage-related announcements and the blog posts.
On one end of the spectrum you have Supabase - a very Vercel-esque "developer platform" with tiered offerings that ensure that you're paying more than you're using.
On the other end of the spectrum you have Fly - a very Lambda-esque offering with hyper-specific per-second per-memory per-cpu pricing where you'll probably end up paying too little and getting performance hits.
I really do not understand why people would do either when things like Cloudflare Workers (et al) exist. Why do people still want to worry about scaling?
Fly has really straightforward monthly pricing that’s not Lambda like at all, but CF workers pricing model is more similar to Lambda between the two.
It's also unlikely that Cloudflare will offer a true Postgres option; their whole ethos is that anything you deploy is deployed globally, whereas relational databases enforce having a single server as a definition of truth. But I'd love to be proven wrong here.
(I'm sure those use-cases exist, but I'm not sure if they exist inside the use-cases Supabase supports)
Postgres is simply a much more feature-ful option. Going with database-per-tenant with e.g. Cloudflare D1 (besides the fact that D1 is still in beta, technically, but that's important when we're talking about databases) is a specific architectural decision that has its own tradeoffs (like making analytics much more difficult).
Is there some coordination happening to make sure they are in the same data centre?
Edit: I should have read the article. All explained in the first paragraphs that the db is hosted on Fly infrastructure.
Integrated billing is very nice, though.
I love Heroku, render and neon is promising - but non allow access to the WAL.
AFAIK all the others mentioned do not allow logical replication as you noted.
My understanding of Fly Postgres is they put a lot into the tools to orchestrate, but there is not centralized monitoring and in the event of a failure it is up to you to realize and remediate.
Disclaimer: Was part of the team that built Heroku Postgres, and know the Fly team pretty well but don't personally use Fly Postgres so it's my understanding from the team. We've had a number of customers leverage Crunchy Bridge (build by a lot of the original Heroku Postgres team) use us for the managed Postgres connected to fly.io via Tailscale.
Management is a huge difference of course, but I was mostly asking about the database from the point of view of a user of the database. It doesn't sounds like Fly Postgres is doing anything like running your database globally - you still have single instance of the database.
Apologies if I'm missing some details. I intentionally try to stay out of the technical devops type stuff. I'm the kind of person who just pays Heroku for a Postgres and doesn't think much about it after that.
I'm not sure the full details on supabase as it's more recent.
This is a pretty good breakdown of various database providers and in particular a lot paired with Fly - https://dancroak.com/webstack/
i expect supabase will do it too at some point.
That being said, we understand that for startups it might be easier to have pg_bm25 directly within their production database, especially if data volume is small. We're actively open to working with other Postgres-as-a-Service providers in the space to make this possible :)
I have some reservations about machines but none of them have been actual problems yet :)