Neon CEO here.

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.

hey nikita, just checking the 100% postgres compatibility.

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)

Agree on the callout. This one we are going to enable soon so it's fixable. So the correction is that it's architecturally possible, but temporarily disabled. Hope we will be able to run Supabase on it soon!

Also there are some storage plugins that won't work b/c we take over Postgres low level storage.

Likewise in Vitess. It is architecturally possible to add 100% compatibility :)

Well it’s much much harder. Query plans over the distributed system should be different and transaction coordination is different when queries span shards.

It’s impossible to give 100% performance compatibility.

Vitess maintainer here. I feel like the discussion was about 100% feature (queries/protocol/...) compatibility and that somehow it shifted to 100% performance compatibility? 100% performance compatibility is trivially not something to claim.

I'm interested in Neon and considering migrating to it. A few questions that I couldn't find a quick answer to:

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.

1. Right now cold start is 3-5 sec. We are actively working on bringing it down. This is our users #1 complaint

2. Yes to pg bouncer. You have two connection strings with and without it

3. Yes. Check out our serverless driver.

Thanks for answering!

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?

That's pretty cool, only heard about planetscale cause of their advanced query caching blog post a while ago.

But the lack of postgres was why I never used it. I'll have to give neon a go.