Cool article, thanks for sharing.<p>You don't mention which version of HTTP you were using, which makes some of my comments here conjecture, but if I had to guess, I'd say you were using HTTP/1.1. Is that right?<p>It would really help if you could break down where the time is being spent. I'd love to know what fraction of the time is spent in processing, transit, querying the db, etc.<p>Did you consider HTTP/2 or 3? I would expect them to have lower setup overhead, and be more competitive with Websockets.<p>In particular, if you were using HTTP/2+, did you look into CONNECT proxying? It could replace Websockets while having lower connection setup overhead, albeit at the cost of a little payload unwrapping overhead in the proxy. But theoretically, this could offer both the faster startup of HTTP/2+, combined with the lower processing overhead for the db of a TCP stream. Comparing the graphs of 10 queries, it _appears_ that processing HTTP imposes a ~15 ms overhead over raw bytes. (Theoretically, the CONNECT proxy has to obey the host and port in the :authority pseudoheader, but in your case, the proxy would just ignore it, and hook up the edge function to whatever compute node it pleased.)
It seems like if speed was a concern you wouldn't make the extra hop from a serverless function to their websocket server, then on to the db. Instead you could serve your api directly off the app server which would then connect to the db without the intermediary step.
But why?<p>The edge is in general not the users browser.<p>So you can do a TLS/postgres connection instead of adding additional layers.<p>Sure you want to probably run a patched pg client/server which has various optimizations to reduce the number of round trips when opening a connection, but that also applies to any HTTP/WebSocket wrapper.
What I would absolutely love is to have a proxy server that would act as postgres, and use this new driver to connect to a remote postgres. This would avoid us having to rewrite our remote agents (which require a postgres connection to the main Database) to use an http api. Instead, we could just keep them as it is, using rust's sqlx queries, point them to the local proxy. Essentially pgBouncer but through http.<p>Postgres <> Neon HTTP Proxy <---HTTP---> Local Fake Postgres Server <--unix socket--> Agents<p>We need it for the open-source project windmill.dev and we will build this if no one else does it.
I tried making a realtime multiplayer game network based on HTTP, sending movement data every 100ms and individual world changes on each HTTP requests by that was taking 50ms each on a wifi local network, I thought that was good enough but then I tested websockets and the round-trip for websocket was around 4ms.
Here is the actual package used [1]. I thought it would have been similar to serverless-pg[2] with initiation outside the handler as with the node implementation. Any insights into how they achieve connection caching (similar to pooling?) on the edge?<p>[1]: <a href="https://github.com/neondatabase/serverless">https://github.com/neondatabase/serverless</a>
[2]: <a href="https://github.com/MatteoGioioso/serverless-pg">https://github.com/MatteoGioioso/serverless-pg</a>
The biggest selling point of websockets over http is that you can stream the results back easily and quickly, which enables stuff like canceling slow queries easily, a transfer progress bar, etc.
@raoufchebri & @nikita, What about comparisons to CloudFlare Workers using Workers Sock API to connect to PG? [1] I know CloudFlare workers support Neon directly through API so how does that compare to the alternative PG implementations?<p>[1] <a href="https://developers.cloudflare.com/workers/learning/integrations/databases/" rel="nofollow noreferrer">https://developers.cloudflare.com/workers/learning/integrati...</a>
<a href="https://news.ycombinator.com/item?id=33909616">https://news.ycombinator.com/item?id=33909616</a> history. Why were sockets used in the first place?<p>Neon is slow and flaky I am thankful you are making changes but strongmanning your technical choice when you are wrong is concerning as a user. I still use Neon due to not being able to move back to heroku. I also you keep making open source more.