Much much better :)
On a serious note, Neon is Postgres and Planetscale is MySQL. Neon has 100% compat with Postgres and Planetscale supports most but not all MySQL. Neon has unlimited storage a single node compute. Planetscale is scale out architecture on top of Vitess.
Neon scales to 0 and more cost effective b/c the architecture.
From what I understand there isn't any logical replication: https://community.neon.tech/t/plans-for-logical-replication/...
This prevents makes it incompatible with our Realtime server and a few other CDC tools like Debezium
(mentioned previously: https://news.ycombinator.com/item?id=33912348)
Also there are some storage plugins that won't work b/c we take over Postgres low level storage.
It’s impossible to give 100% performance compatibility.
1. When scaling to zero, what is the cold start for a request (including the time needed to make the connection)? Do you have benchmarks on this you could share?
2. Does Neon run a pgbouncer service or are customers expected to run their own? Is it better for AWS lambda functions to leave a connection open for the duration of the container lifecycle or open/close on each request?
3. Does Neon support HTTP for doing queries like serverless Aurora v1 does with its Data API? The use-case I have is direct AppSync GraphQL resolvers, not V8 isolate runtimes.
2. Yes to pg bouncer. You have two connection strings with and without it
3. Yes. Check out our serverless driver.
I saw your serverless driver, but it looks like it uses WSS, not HTTP. Is that correct, or is there an HTTP variant as well?
But the lack of postgres was why I never used it. I'll have to give neon a go.