Supabase egress pricing is ridiculous

[Dima-M]

Fly Supabase pricing makes little sense as Fly Postgres managed replacement due to tight “egress” traffic limits. Apparently, Fly Supabase charges traffic to your own Supabase machines as “egress” - while I believe Fly Postgress’s traffic (to Fly VMs) would be unmetered.

I had a small app that required certain micro-batch ETL (ETL runs on Fly VM) and it consumed the Free Tier’s 5GB in a matter of 3 days even on very small amounts of dummy data. Pro Tier’s 250GB would also be gone within a month easily as the real app’s usage begins.

@Fly team - as you extend their partnership and integration with Supabase, do you plan any kind of better solution to Supabase ↔ Fly (inside same org) traffic metering, or it will follow the existing same mode (all traffic metered and charged)?

Making a decision right now whether to proceed with Fly Postgres or Supabase.

[pkpkpk]

Do you feel like you’ve got a pretty solid understanding of how to admin a cluster with repmgr? Because if anything goes wrong with your fly postgres you’ll need to.

[mabis]

Supabase does unified egress, you should be able to see a breakdown of the different types of egress on your org usage page (Supabase’s, not Fly’s) and get an idea of what is consuming more than you expected.

I haven’t delved much into this but I suspect it’s the WAL-G continuous stream to S3 for backups since it goes out of Fly and into AWS.