storm widget
Deno Deploy is hosted on Google Cloud, but I was wondering: is a database service from another company, but also hosted on Google Cloud, would result in a good latency that resolve inside the same region datacenter, or will it fatally get out in the internet and induce terrible latency?
What about a database service hosted on AWS then?
Is anybody have numbers to share?
dreamy pivot
I’ve never used deno deploy, but can’t you have the database on the same machine?
drifting adder
I like to use MongoDB with Atlas 
You can host your db with Google Cloud too,
and also pick up a region
elder igloo
I’ve never used deno deploy, but can’t you have the database on the same machine...
No
frozen python
@dreamy pivot Deploy spins up V8 isolates that run code pulled from a Github repo (I imagine GH runs on Azure)... these "edge functions" only live for a while and preserve no local state on Deploy. (Like AWS Lamba but I'd never needed that either, not my usual use case, I want my MTV, I mean my Postgres db.) So I really like the idea of Supabase with DD but as I'm sure @storm widget already noticed, Supa runs on AWS. So the default for a Google Cloud user would probably be Firebase.
If I was going to try to reduce this stack's dependencies from 3 clouds to 2 while keeping Postgres, I would rather try to self-manage a Supabase install or vanilla Pg on a Google VM. Or if I could slip to SQLite, try Pocketbase on a VM. But I am still coming out of my colo'd self-managed control freak ways and have never scaled anything beyond 2 data centres so keep in mind I know nothing.
@storm widget you were looking for numbers, I don't have any but my intuition is that a service that by design runs in dozens of sites and talks to a back end that also runs in dozens of sites will normally be really fast. Except when it's really not. That complexity is really unappealing, hard to debug, so probably hard to sell. But it is so only because the underlying problem is complex. They've solved so much of that (like using V8 isolates instead of containers or VMs), hopefully solutions also exist (or will soon) so we don't have to do the equivalent of a Linux distro install's "find the fastest mirror" on each spin-up.
I think more than ongoing latency those initial post-spin-up (discovery, ping, DNS, wait for some other back end(s) to wake up) are likely to be the more slow points to try to iron out. But I only get to play with this on weekends at the moment so no facts for you, just opinions. Will let you know when I learn anything more useful, look forward to your discoveries as well.
storm widget
Thank you everyone. Guess I gotta test all the databases services and then I will know with actual numbers 😄