> So now they contradict their premise that they solved reading and writing in a distributed way and go back to say on second thought, nevermind, we can't handl

> So now they contradict their premise that they solved reading and writing in a distributed way and go back to say on second thought, nevermind, we can't handle distributed writes because it's hard. Fwiw, even Postgres-centered "real-time" platforms like Supabase do not do distributed writes (but they sure can benefit from distributed reads). > I appreciate what they're trying to do but they send mixed signals around solving a problem they haven't solved which also happens to be tied into their biggest selling point (globally distributed deployments so that end users have low latency responses). I get where you are coming from, but I'd imagine Supabase on Fly is instantly faster than its default single-region deploys on AWS. Fly's CEO, Kurt Mackey, is an investor in Supabase, so let's see how that partnership pans out. Fly's primary/read replica setup is as good as it gets without complicating matters any further. My money would be on Fly.io to rope in CoakroachDB, PlanetScale, YugaByte, CitusData as solution partners, but that's easier said than done. > I took a screenshot of it in case it gets edit here: https://imgur.com/a/eY6EJ0e https://imgur.com/a/eY6EJ0e You could use archive.is (https://archive.is/rlxsS https://archive.is/rlxsS) or web.archive.org/save, too (: