8 ms·

Fly Postgres, Managed by Supabase

292 points by samwillis 3y ago

biorach 3y ago
Excellent news
kiwicopple 3y ago
hey hn, supabase ceo here 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/ https://fly.io/docs/reference/redis/
- denysvitali 3y ago
  Two awesome technologies / companies joining forces! Supabase and Fly.io are awesome - can't wait to see how cool they can get together!
- adam_gyroscope 3y ago
  Nice job & congrats!
- pplante 3y ago
  You used the lowercase, it's cool we're all friends here in your intro. Then reverted to correct casing for the remainder. Disarmed everyone with that sly move. nice touch!
  - saintfire 3y ago
    It is sort of funny that such an innocuous thing was all I could think about while reading it.
    - kiwicopple 3y ago
      ha, I think I probably wrote "Fly" to keep their brand name and then continued in blog-writing mode as a result
  - OJFord 3y ago
    Amazing, that was exactly my (only) reaction too. 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.
    - kiwicopple 3y ago
      you mock my capitalization and and in the same comment use "thenceforth". shame on you
      - OJFord 3y ago
        Is there a less 'wordy' way to say that? 'From then on' is longer and worse to type. That matters to me more on (autocapitalising) mobile than it perhaps does otherwise. 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?
        tptacek 3y ago
        Based on insight I have gained from the deep corporate relationship that has grown between our firms I can say with some confidence that he is fucking with you.
        bmelton 3y ago
        Mathematically speaking, 'henceforth' is shorter
        OJFord 3y ago
        And linguistically speaking, has different meaning.
        deleted 3y ago
  - deleted 3y ago
    [deleted]
- satvikpendem 3y ago
  Interesting, why doesn't Fly offer their own managed services and move up-market like DigitalOcean and others (and of course, the big cloud players)? I haven't heard of other companies coming in to collaborate on managing the hosted version of other companies' unhosted service.
  - KRAKRISMOTT 3y ago
    They lack the institutional DNA and culture for site reliability engineering. They have amazing system engineers and this is rather obvious from their blogposts. However their uptime numbers are frankly horrifying and in their support forums they spend a lot of time making customers do the work for them. They don't have the institutional culture to be running modern cloud infrastructure. Good engineers, terrible operators.
    - cultofmetatron 3y ago
      > However their uptime numbers are frankly horrifying and in their support forums they spend a lot of time making customers do the work for them 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
    - biorach 3y ago
      I think you're being unfairly harsh. Looks to me like they're improving.
  - tptacek 3y ago
    They're related but distinct problem spaces. Craig Kerstiens is somewhere else on this thread talking about the work that went into Heroku's Postgres. Paul Copplestone can give you an earful about how hard Supabase was to build. We can talk your ears off about orchestration and Anycast networking. These are all big problems; they're not just features. 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. :)
- jerrygoyal 3y ago
  Hi, what are your thoughts on distributed SQLite? Do you see it's becoming the default choice instead of pgs in future?
  - devoutsalsa 3y ago
    ThePrimeagen (dev YouTuber: https://youtube.com/@ThePrimeagen https://youtube.com/@ThePrimeagen) talks about liking Turso quite a bit, which is built on SQLite. I haven’t tried it, but it sounds fun. https://turso.tech/ https://turso.tech/
jsierles 3y ago
Joshua from the Fly.io side here, happy to answer any questions about this integration.
- nicoburns 3y ago
  Very excited for this. Aside from general reliability concerns (esp. around deploys - not helped by cryptic failure messages). Lack of managed Postgres has been the main thing keeping me off fly (I use it for a couple of side projects, but nothing big yet). And blob storage would probably be next on my list (basically stateful things are the things I want managed) so also excited to see that's being worked on. Do you have any details on pricing (for this new postgres offering) yet?
  - kiwicopple 3y ago
    (supabase team jumping in) this will follow our current pricing: https://supabase.com/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
    - nicoburns 3y ago
      EDIT: Oh, perhaps it follows this table? https://supabase.com/docs/guides/platform/compute-add-ons https://supabase.com/docs/guides/platform/compute-add-ons --- 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?
    - pier25 3y ago
      So $25 per month/DB and then usage based? Is bandwidth also paid considering it will be only used in the internal Fly network?
philip1209 3y ago
I'm excited to switch to this - I've been building Booklet on Fly.io and their Postgres to make the app distributed [1]. The biggest problem for me has been the Fly postgres configuration. Specifically, Fly puts HAProxy in front of Postgres with a 30m connection timeout [2], which keeps killing connections. This should be manageable, but I'm seeing quirks in the connection terminations that don't seem to align with their docs and keep causing instability. 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/ https://www.contraption.co/essays/booklet-architecture/ [2] https://community.fly.io/t/postgresql-connection-issues-have-returned/6424 https://community.fly.io/t/postgresql-connection-issues-have...
- kiwicopple 3y ago
  it will have our own connection pooler[0] for Postgres connections instead of HAProxy, as well as PostgREST[1] for REST [0] https://supabase.com/blog/supavisor-postgres-connection-pooler https://supabase.com/blog/supavisor-postgres-connection-pool... [1] https://postgrest.org/ https://postgrest.org/
plondon514 3y ago
Very excited about this. We’re currently running a large db on fly and looking for a managed pg. We’re a fully Elixir shop and this couldn’t have come at a better time. Congrats to both teams!
- jononomo 3y ago
  How is this better than just signing up for an account at supabase.com and then giving your Elixir app the DB credentials?
candiddevmike 3y ago
Where's the SLA?
nextworddev 3y ago
I heard Supabase has known to have scaling issues beyond prototype projects, can anyone comment who has production experience with it?
- tmountain 3y ago
  It’s Postgres running on AWS, so it should scale as well as one would expect with that combination. What issues are you referring to specifically?
  - kiwicopple 3y ago
    yes it has the same scaling parameters as RDS (and soon we'll have a few other ways to scale beyond) 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 https://twitter.com/seif_ghezala/status/1734967554659983418 [0] https://news.ycombinator.com/item?id=36004925 https://news.ycombinator.com/item?id=36004925 [1] https://news.ycombinator.com/item?id=37059401 https://news.ycombinator.com/item?id=37059401
    - refulgentis 3y ago
      Wow Pika runs on Supabase!?! Congrats. 800K!? I can officially tell myself to stop worrying about scaling before launching, probably even for a couple years
leros 3y ago
I understand the neatness of fly.io's distributed VMs. Can someone explain how Fly Postgres is different than a traditional managed Postgres on something like Heroku.
- tptacek 3y ago
  We wrote a blog post about this: https://fly.io/blog/how-we-built-fly-postgres/ https://fly.io/blog/how-we-built-fly-postgres/
  - leros 3y ago
    If I'm understanding correctly, Fly Postgres isn't too different from something like Postgres on Heroku? It's a single instance/cluster in a single location.
    - craigkerstiens 3y ago
      I don't think that's correct at all. Heroku Postgres has a central control plane that is monitoring availability and orchestrating things. There are continual health checks that go back to Heroku. In the event of unavailability it sets off a page to the on-call engineer to investigate if systems haven't restored availability. 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.
      - tptacek 3y ago
        Yeah! One way to think about it that is almost (not perfectly) correct is that you could build and run all of Fly Postgres yourself; it's almost just a Fly App configuration.
      - 3y ago
smallerfish 3y ago
Very nice. I've never really liked Supabase's network restrictions setup (https://supabase.com/docs/guides/platform/network-restrictions https://supabase.com/docs/guides/platform/network-restrictio...), and IIRC when I looked at it there was some weird issue exposing the Fly IP for your app to Supabase, and locking Supabase down to it. Having Supabase actually within the Fly network is great. Congrats to both teams.
- loloquwowndueo 3y ago
  The issue here would be that fly.io doesn’t guarantee outgoing IP addresses to be consistent so you can’t allowlist based on originating IP. This is mentioned in fly.io networking documentation.
  - tptacek 3y ago
    Oh, wow, I forgot that this (database ingress filtering) was a big motivator for the engineering project we were considering for giving apps persistent outbound IP addresses, a project I loathe and now have another arrow in my quiver with which to shoot it down. 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).
    - Alacart 3y ago
      Why do you loathe it? Coming from someone who kind of wants it.
      - tptacek 3y ago
        Infra engineering is the most important, hardest engineering practice in the company. I'm not one, and the people who want to do this are. So leave a lot of space here for me just being wrong. 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!
trevor-e 3y ago
I looked into Supabase a while back but left confused on how to do a basic REST API. They auto-generate an API to interact with the tables you create which sounds neat, but like, where does the business logic live? I then checked out their edge functions but it wasn't clear if they are meant to be used that way since the examples are more oriented for tasks. Seems like I'm not understanding something simple here.
- Mortiffer 3y ago
  core element is https://postgrest.org/en/stable/ https://postgrest.org/en/stable/ . I use this in production in large corporate projects on k8s. For a large number of use cases you can put logic into stored procedures SQL. PG can also do JS or Py stored procedures but you get a better developer experience if your logic code is deployed through regular CI/CD containers or functions (we use both extensively together depending on cost trade offs either one.) 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.
  - trevor-e 3y ago
    Interesting, thanks for the info. I thought they were targeting mobile developers since they claim to replace Firebase, but sounds like a mobile app API wouldn't fit their platform very well. That explains why I was very confused trying to use their mobile SDK for iOS lol.
  - refulgentis 3y ago
    AFAIK Supabase serverless is Cloudflare, or at least I thought...
    - pcnc 3y ago
      It previously ran on Deno, but now we run our own edge runtime! https://github.com/supabase/edge-runtime https://github.com/supabase/edge-runtime
OJFord 3y ago
Ha, this is weird. I noticed this earlier today in Fly docs and was surprised I'd missed it on HN (as surely it would've appeared). I didn't realise it was new. 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.)
- xena 3y ago
  Fly.io employee here. Go with Supabase if you want a managed database. Fly.io Postgres is unmanaged. This is the key difference, yes.
  - nomilk 3y ago
    Can you ELI5 the difference? Especially any sharp edges + pros/cons. I suspect I'm not alone coming from managed postgres (e.g. heroku or similar) and am open minded to unmanaged but don't want to unknowingly make a poor infra decision.
    - tptacek 3y ago
      Managed database offerings give you a Postgres URL and you just go to town. They take care of scaling and monitoring. Fly Postgres is automated, but not managed: our tooling will boot up a Postgres cluster for you, at a specified size, but it's not going to do so much database-level monitoring that you can forget about the database and just assume it's always healthy regardless of your usage. 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.
TobyTheDog123 3y ago
These two companies have pricing models that I just absolutely hate. 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?
- revskill 3y ago
  It's all about Posgresql ecosystem, DX and other addons.
- alphabettsy 3y ago
  Trying running any random Docker container you might need on Cloudflare workers and you’ll see why. 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.
- solatic 3y ago
  Cloudflare Workers doesn't offer a Postgres option. At most, there's Hyperdrive to connect to Postgres hosted elsewhere, and even then Hyperdrive is essentially a connection pooler, with all the additional restrictions that places on you. 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.
  - TobyTheDog123 3y ago
    You're right - I should have clarified that I'm talking about new projects - as in "Why would someone choose Postgres over one of these distributed SQLite providers for a new project?" (I'm sure those use-cases exist, but I'm not sure if they exist inside the use-cases Supabase supports)
tehlike 3y ago
There is lots of money to be saved by using hetzner + hetzner-k3s + cloudnativepg or crunchydata postgres operator.
- rywalker 3y ago
  cloudnativepg is great, we're using it as a foundational component to Tembo's OSS and Cloud services (tembo.io).
- revskill 3y ago
  k3s is hard to manage, it required a bunch of money there.
  - tehlike 3y ago
    It's really not that bad.
  - tptacek 3y ago
    Say more? Super interested in any backstory or insight here b/c rsns.
surfmike 3y ago
how is fly.io reliability these days?
- lawik 3y ago
  Mostly better from the client project where we run them. Haven't had as many disruptions since shifting from their nomad offering to machines. I have some reservations about machines but none of them have been actual problems yet :)
  - mrkurt 3y ago
    I would love to hear your reservations. We've made some choices for simplicity that I expected us to have to engineer around, but a surprising number of them haven't been problems in practice. In short, I have reservations too.
canadiantim 3y ago
Is there any thought towards adopting ParadeDB within supabase? Or atleast using the extensions they develop?
- rywalker 3y ago
  We're actively working towards adding ParadeDB to Tembo Cloud (cloud.tembo.io) - feel free to message us in app to get alpha access. i expect supabase will do it too at some point.
- philippemnoel 3y ago
  ParadeDB developer here -- we're developing a way for users to no zero-ETL sync between any managed Postgres and ParadeDB, so that you can get a dedicated search node on Postgres without slowing down your production DB. We expect this will be the primary way in which people use ParadeDB in the future. 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 :)
  - kiwicopple 3y ago
    feel free to reach out if you want to explore something for supabase devs - we love collaborating with others in the ecosystem
timenova 3y ago
> Fly machines don't have network-attached storage, so we treat any data in Fly volumes as ephemeral. 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?
- tptacek 3y ago
  No. Fly Volumes are attached NVME storage; they're anchored to the physical host they're created on. 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.
  - timenova 3y ago
    Thanks for the detailed reply! Looking forward to more storage-related announcements and the blog posts.
stevoski 3y ago
What’s the latency like, when hosting your app on Fly, and your db on Supabase? 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.
jnsaff2 3y ago
For those who did not get the SupaFly reference a fun watch: https://www.youtube.com/results?search_query=joe+cartoon+superfly https://www.youtube.com/results?search_query=joe+cartoon+sup...
twsted 3y ago
Does anyone know if there is a comparison somewhere for the various Postgres offerings (eg heroku, aws, crunchydata, fly, supabase, etc)), both managed and unmanaged, with features and pricing?
- jadayesnaamsi 3y ago
  I am particularly interested in a comparaison between this new one from Supabase/Fly and the one from Neon.
  - cpursley 3y ago
    Main thing I want to know: which of the managed Postgres services allow for logical replication. I love Heroku, render and neon is promising - but non allow access to the WAL.
    - kevinbrolly 3y ago
      Hey, supabase employee here. We allow you to use logical replication - https://supabase.com/docs/guides/database/replication https://supabase.com/docs/guides/database/replication AFAIK all the others mentioned do not allow logical replication as you noted.
    - SahAssar 3y ago
      Can I ask what your use-case is for logical replication on something like neon?
      - cpursley 3y ago
        So I can run something like Supabase or WalEx which subscribe to WAL changes.
        SahAssar 3y ago
        Ah, gothca. I've mostly used triggers and LISTEN/NOTIFY for those things, so haven't tried the WAL methods.
jononomo 3y ago
How is this different from just deploying an application on a Fly.io machine and then giving it the DB credentials to connect to a Supabase instance?
- mixmastamyk 3y ago
  Sounds like better performance (db is in on site) and integrated billing.
  - jononomo 3y ago
    What do you mean on-site? Isn’t the whole point of Fly that you run your apps at the edge? Integrated billing is very nice, though.

292 points by samwillis 3y ago

Excellent news

hey hn, supabase ceo here 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/ https://fly.io/docs/reference/redis/

denysvitali 3y ago
Two awesome technologies / companies joining forces! Supabase and Fly.io are awesome - can't wait to see how cool they can get together!
adam_gyroscope 3y ago
Nice job & congrats!
pplante 3y ago
You used the lowercase, it's cool we're all friends here in your intro. Then reverted to correct casing for the remainder. Disarmed everyone with that sly move. nice touch!
- saintfire 3y ago
  It is sort of funny that such an innocuous thing was all I could think about while reading it.
  - kiwicopple 3y ago
    ha, I think I probably wrote "Fly" to keep their brand name and then continued in blog-writing mode as a result
- OJFord 3y ago
  Amazing, that was exactly my (only) reaction too. 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.
  - kiwicopple 3y ago
    you mock my capitalization and and in the same comment use "thenceforth". shame on you
    - OJFord 3y ago
      Is there a less 'wordy' way to say that? 'From then on' is longer and worse to type. That matters to me more on (autocapitalising) mobile than it perhaps does otherwise. 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?
      - tptacek 3y ago
        Based on insight I have gained from the deep corporate relationship that has grown between our firms I can say with some confidence that he is fucking with you.
      - bmelton 3y ago
        Mathematically speaking, 'henceforth' is shorter
        OJFord 3y ago
        And linguistically speaking, has different meaning.
        deleted 3y ago
- deleted 3y ago
  [deleted]
satvikpendem 3y ago
Interesting, why doesn't Fly offer their own managed services and move up-market like DigitalOcean and others (and of course, the big cloud players)? I haven't heard of other companies coming in to collaborate on managing the hosted version of other companies' unhosted service.
- KRAKRISMOTT 3y ago
  They lack the institutional DNA and culture for site reliability engineering. They have amazing system engineers and this is rather obvious from their blogposts. However their uptime numbers are frankly horrifying and in their support forums they spend a lot of time making customers do the work for them. They don't have the institutional culture to be running modern cloud infrastructure. Good engineers, terrible operators.
  - cultofmetatron 3y ago
    > However their uptime numbers are frankly horrifying and in their support forums they spend a lot of time making customers do the work for them 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
  - biorach 3y ago
    I think you're being unfairly harsh. Looks to me like they're improving.
- tptacek 3y ago
  They're related but distinct problem spaces. Craig Kerstiens is somewhere else on this thread talking about the work that went into Heroku's Postgres. Paul Copplestone can give you an earful about how hard Supabase was to build. We can talk your ears off about orchestration and Anycast networking. These are all big problems; they're not just features. 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. :)
jerrygoyal 3y ago
Hi, what are your thoughts on distributed SQLite? Do you see it's becoming the default choice instead of pgs in future?
- devoutsalsa 3y ago
  ThePrimeagen (dev YouTuber: https://youtube.com/@ThePrimeagen https://youtube.com/@ThePrimeagen) talks about liking Turso quite a bit, which is built on SQLite. I haven’t tried it, but it sounds fun. https://turso.tech/ https://turso.tech/

jsierles 3y ago

Joshua from the Fly.io side here, happy to answer any questions about this integration.

nicoburns 3y ago
Very excited for this. Aside from general reliability concerns (esp. around deploys - not helped by cryptic failure messages). Lack of managed Postgres has been the main thing keeping me off fly (I use it for a couple of side projects, but nothing big yet). And blob storage would probably be next on my list (basically stateful things are the things I want managed) so also excited to see that's being worked on. Do you have any details on pricing (for this new postgres offering) yet?
- kiwicopple 3y ago
  (supabase team jumping in) this will follow our current pricing: https://supabase.com/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
  - nicoburns 3y ago
    EDIT: Oh, perhaps it follows this table? https://supabase.com/docs/guides/platform/compute-add-ons https://supabase.com/docs/guides/platform/compute-add-ons --- 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?
  - pier25 3y ago
    So $25 per month/DB and then usage based? Is bandwidth also paid considering it will be only used in the internal Fly network?

philip1209 3y ago

I'm excited to switch to this - I've been building Booklet on Fly.io and their Postgres to make the app distributed [1]. The biggest problem for me has been the Fly postgres configuration. Specifically, Fly puts HAProxy in front of Postgres with a 30m connection timeout [2], which keeps killing connections. This should be manageable, but I'm seeing quirks in the connection terminations that don't seem to align with their docs and keep causing instability. 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/ https://www.contraption.co/essays/booklet-architecture/ [2] https://community.fly.io/t/postgresql-connection-issues-have-returned/6424 https://community.fly.io/t/postgresql-connection-issues-have...

kiwicopple 3y ago
it will have our own connection pooler[0] for Postgres connections instead of HAProxy, as well as PostgREST[1] for REST [0] https://supabase.com/blog/supavisor-postgres-connection-pooler https://supabase.com/blog/supavisor-postgres-connection-pool... [1] https://postgrest.org/ https://postgrest.org/

plondon514 3y ago

Very excited about this. We’re currently running a large db on fly and looking for a managed pg. We’re a fully Elixir shop and this couldn’t have come at a better time. Congrats to both teams!

jononomo 3y ago
How is this better than just signing up for an account at supabase.com and then giving your Elixir app the DB credentials?

candiddevmike 3y ago

Where's the SLA?

nextworddev 3y ago

I heard Supabase has known to have scaling issues beyond prototype projects, can anyone comment who has production experience with it?

tmountain 3y ago
It’s Postgres running on AWS, so it should scale as well as one would expect with that combination. What issues are you referring to specifically?
- kiwicopple 3y ago
  yes it has the same scaling parameters as RDS (and soon we'll have a few other ways to scale beyond) 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 https://twitter.com/seif_ghezala/status/1734967554659983418 [0] https://news.ycombinator.com/item?id=36004925 https://news.ycombinator.com/item?id=36004925 [1] https://news.ycombinator.com/item?id=37059401 https://news.ycombinator.com/item?id=37059401
  - refulgentis 3y ago
    Wow Pika runs on Supabase!?! Congrats. 800K!? I can officially tell myself to stop worrying about scaling before launching, probably even for a couple years

leros 3y ago

I understand the neatness of fly.io's distributed VMs. Can someone explain how Fly Postgres is different than a traditional managed Postgres on something like Heroku.

tptacek 3y ago
We wrote a blog post about this: https://fly.io/blog/how-we-built-fly-postgres/ https://fly.io/blog/how-we-built-fly-postgres/
- leros 3y ago
  If I'm understanding correctly, Fly Postgres isn't too different from something like Postgres on Heroku? It's a single instance/cluster in a single location.
  - craigkerstiens 3y ago
    I don't think that's correct at all. Heroku Postgres has a central control plane that is monitoring availability and orchestrating things. There are continual health checks that go back to Heroku. In the event of unavailability it sets off a page to the on-call engineer to investigate if systems haven't restored availability. 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.
    - tptacek 3y ago
      Yeah! One way to think about it that is almost (not perfectly) correct is that you could build and run all of Fly Postgres yourself; it's almost just a Fly App configuration.
    - 3y ago

smallerfish 3y ago

Very nice. I've never really liked Supabase's network restrictions setup (https://supabase.com/docs/guides/platform/network-restrictions https://supabase.com/docs/guides/platform/network-restrictio...), and IIRC when I looked at it there was some weird issue exposing the Fly IP for your app to Supabase, and locking Supabase down to it. Having Supabase actually within the Fly network is great. Congrats to both teams.

loloquwowndueo 3y ago
The issue here would be that fly.io doesn’t guarantee outgoing IP addresses to be consistent so you can’t allowlist based on originating IP. This is mentioned in fly.io networking documentation.
- tptacek 3y ago
  Oh, wow, I forgot that this (database ingress filtering) was a big motivator for the engineering project we were considering for giving apps persistent outbound IP addresses, a project I loathe and now have another arrow in my quiver with which to shoot it down. 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).
  - Alacart 3y ago
    Why do you loathe it? Coming from someone who kind of wants it.
    - tptacek 3y ago
      Infra engineering is the most important, hardest engineering practice in the company. I'm not one, and the people who want to do this are. So leave a lot of space here for me just being wrong. 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!

trevor-e 3y ago

I looked into Supabase a while back but left confused on how to do a basic REST API. They auto-generate an API to interact with the tables you create which sounds neat, but like, where does the business logic live? I then checked out their edge functions but it wasn't clear if they are meant to be used that way since the examples are more oriented for tasks. Seems like I'm not understanding something simple here.

Mortiffer 3y ago
core element is https://postgrest.org/en/stable/ https://postgrest.org/en/stable/ . I use this in production in large corporate projects on k8s. For a large number of use cases you can put logic into stored procedures SQL. PG can also do JS or Py stored procedures but you get a better developer experience if your logic code is deployed through regular CI/CD containers or functions (we use both extensively together depending on cost trade offs either one.) 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.
- trevor-e 3y ago
  Interesting, thanks for the info. I thought they were targeting mobile developers since they claim to replace Firebase, but sounds like a mobile app API wouldn't fit their platform very well. That explains why I was very confused trying to use their mobile SDK for iOS lol.
- refulgentis 3y ago
  AFAIK Supabase serverless is Cloudflare, or at least I thought...
  - pcnc 3y ago
    It previously ran on Deno, but now we run our own edge runtime! https://github.com/supabase/edge-runtime https://github.com/supabase/edge-runtime

OJFord 3y ago

Ha, this is weird. I noticed this earlier today in Fly docs and was surprised I'd missed it on HN (as surely it would've appeared). I didn't realise it was new. 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.)

xena 3y ago
Fly.io employee here. Go with Supabase if you want a managed database. Fly.io Postgres is unmanaged. This is the key difference, yes.
- nomilk 3y ago
  Can you ELI5 the difference? Especially any sharp edges + pros/cons. I suspect I'm not alone coming from managed postgres (e.g. heroku or similar) and am open minded to unmanaged but don't want to unknowingly make a poor infra decision.
  - tptacek 3y ago
    Managed database offerings give you a Postgres URL and you just go to town. They take care of scaling and monitoring. Fly Postgres is automated, but not managed: our tooling will boot up a Postgres cluster for you, at a specified size, but it's not going to do so much database-level monitoring that you can forget about the database and just assume it's always healthy regardless of your usage. 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.

TobyTheDog123 3y ago

These two companies have pricing models that I just absolutely hate. 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?

revskill 3y ago
It's all about Posgresql ecosystem, DX and other addons.
alphabettsy 3y ago
Trying running any random Docker container you might need on Cloudflare workers and you’ll see why. 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.
solatic 3y ago
Cloudflare Workers doesn't offer a Postgres option. At most, there's Hyperdrive to connect to Postgres hosted elsewhere, and even then Hyperdrive is essentially a connection pooler, with all the additional restrictions that places on you. 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.
- TobyTheDog123 3y ago
  You're right - I should have clarified that I'm talking about new projects - as in "Why would someone choose Postgres over one of these distributed SQLite providers for a new project?" (I'm sure those use-cases exist, but I'm not sure if they exist inside the use-cases Supabase supports)

tehlike 3y ago

There is lots of money to be saved by using hetzner + hetzner-k3s + cloudnativepg or crunchydata postgres operator.

rywalker 3y ago
cloudnativepg is great, we're using it as a foundational component to Tembo's OSS and Cloud services (tembo.io).
revskill 3y ago
k3s is hard to manage, it required a bunch of money there.
- tehlike 3y ago
  It's really not that bad.
- tptacek 3y ago
  Say more? Super interested in any backstory or insight here b/c rsns.

surfmike 3y ago

how is fly.io reliability these days?

lawik 3y ago
Mostly better from the client project where we run them. Haven't had as many disruptions since shifting from their nomad offering to machines. I have some reservations about machines but none of them have been actual problems yet :)
- mrkurt 3y ago
  I would love to hear your reservations. We've made some choices for simplicity that I expected us to have to engineer around, but a surprising number of them haven't been problems in practice. In short, I have reservations too.

canadiantim 3y ago

Is there any thought towards adopting ParadeDB within supabase? Or atleast using the extensions they develop?

rywalker 3y ago
We're actively working towards adding ParadeDB to Tembo Cloud (cloud.tembo.io) - feel free to message us in app to get alpha access. i expect supabase will do it too at some point.
philippemnoel 3y ago
ParadeDB developer here -- we're developing a way for users to no zero-ETL sync between any managed Postgres and ParadeDB, so that you can get a dedicated search node on Postgres without slowing down your production DB. We expect this will be the primary way in which people use ParadeDB in the future. 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 :)
- kiwicopple 3y ago
  feel free to reach out if you want to explore something for supabase devs - we love collaborating with others in the ecosystem

timenova 3y ago

> Fly machines don't have network-attached storage, so we treat any data in Fly volumes as ephemeral. 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?

tptacek 3y ago
No. Fly Volumes are attached NVME storage; they're anchored to the physical host they're created on. 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.
- timenova 3y ago
  Thanks for the detailed reply! Looking forward to more storage-related announcements and the blog posts.

stevoski 3y ago

What’s the latency like, when hosting your app on Fly, and your db on Supabase? 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.

jnsaff2 3y ago

For those who did not get the SupaFly reference a fun watch: https://www.youtube.com/results?search_query=joe+cartoon+superfly https://www.youtube.com/results?search_query=joe+cartoon+sup...

twsted 3y ago

Does anyone know if there is a comparison somewhere for the various Postgres offerings (eg heroku, aws, crunchydata, fly, supabase, etc)), both managed and unmanaged, with features and pricing?

jadayesnaamsi 3y ago
I am particularly interested in a comparaison between this new one from Supabase/Fly and the one from Neon.
- cpursley 3y ago
  Main thing I want to know: which of the managed Postgres services allow for logical replication. I love Heroku, render and neon is promising - but non allow access to the WAL.
  - kevinbrolly 3y ago
    Hey, supabase employee here. We allow you to use logical replication - https://supabase.com/docs/guides/database/replication https://supabase.com/docs/guides/database/replication AFAIK all the others mentioned do not allow logical replication as you noted.
  - SahAssar 3y ago
    Can I ask what your use-case is for logical replication on something like neon?
    - cpursley 3y ago
      So I can run something like Supabase or WalEx which subscribe to WAL changes.
      - SahAssar 3y ago
        Ah, gothca. I've mostly used triggers and LISTEN/NOTIFY for those things, so haven't tried the WAL methods.

jononomo 3y ago

How is this different from just deploying an application on a Fly.io machine and then giving it the DB credentials to connect to a Supabase instance?

mixmastamyk 3y ago
Sounds like better performance (db is in on site) and integrated billing.
- jononomo 3y ago
  What do you mean on-site? Isn’t the whole point of Fly that you run your apps at the edge? Integrated billing is very nice, though.