How scalable and performant is Neon, compared to Supabase?
Could you answer these two questions I posted to the Supabase GitHub discussions, but as it pertains to Neon? I am on the fence about which one to go with (Supabase vs. Neon), because I would like a cloud SQL solution which:
1. Is easy to deploy, use, and autoscale, without being a master devops engineer.
2. Allows for a very large (or infinite) amount of db connections (with automatic pooling for fast startup).
3. Returns most queries in under 1 second.
But I'm so far convinced Supabase doesn't fit that bill. But how about Neon? Here are the links to my questions:
https://github.com/orgs/supabase/discussions/32670
https://github.com/orgs/supabase/discussions/32669
1. Is easy to deploy, use, and autoscale, without being a master devops engineer.
2. Allows for a very large (or infinite) amount of db connections (with automatic pooling for fast startup).
3. Returns most queries in under 1 second.
But I'm so far convinced Supabase doesn't fit that bill. But how about Neon? Here are the links to my questions:
https://github.com/orgs/supabase/discussions/32670
https://github.com/orgs/supabase/discussions/32669
GitHub
ChatGPT provided me with a rough summary table which from reading the Supabase docs, seems pretty accurate: Compute Size Pool Size Max Client Connections Expected Throughput (queries/sec) Small 15 ...
GitHub
I am using edge functions for querying the supabase database. Why does it sometimes say (in the edge function logs, where my db calls are made using Kysely) 6s, 8s, 10 seconds even, to do a query! ...
