> A key feature of these environments is that state is not generally persisted from one request to the next. That means we can’t use standard client-side database connection pooling.<p>So we introduced so many optimizations just because we can't persist state. I can't help but think this is being penny wise pound foolish; the problems this article is solving wouldn't have been problems in the first place if you choose a boring architecture.
Pretty insightful observation on authentication. Using a password method that requires the client to compute a brute force resistant hash that takes ~100ms of cpu time is a non-starter for most serverless platforms.<p>I'm curious if Cloudflare, or other serverless platforms offer the ability to generate short lived JWTs assigned to each worker. Combined with some configuration (pub key exchange, claim setup, etc) a platform like Neon could use these JWTs to establish identity. Sorta SSO for workers without the CPU overhead.<p>Seems like a safer approach than basic auth with fixed pws.
That is some serious optimization. Nice!<p>The article ends with the statement that you are pretty much done here for now. Would optimizing your TLS termination not maybe offer some more ways to speed this up? Or is that also already fully optimized?<p>I did not realize before that your approach with Websockets actually meant that there was no application/client side pooling of connections. What made you choose this approach over an HTTP API (as for example PlanetScale did) anyway?
The end of the post mentions HTTP/3 and QUIC. Planetscale have blogged about this [0].<p>0. <a href="https://planetscale.com/blog/faster-mysql-with-http3" rel="nofollow">https://planetscale.com/blog/faster-mysql-with-http3</a>
With a persistent OS-level network tunnel (ex. wireguard) that exists when the app starts, you wouldn't need HTTP, WebSockets, TLS, etc. The app could open a single TCP connection to a sql connection pool and send its request, and it would be tunneled securely from point to point, with no additional round trips or protocols.<p>The idealist in me would rather this kind of thing become a standardized extension of address + transport protocols. But every person I talk to would rather stack 12 protocols on top of each other than work on improving the existing status quo. It feels like a truism of human societies; everyone wants improvement, but nobody wants fundamental reform.
I didn't know that neon supports using S3 as cold storage. That's seriously amazing. How does that work with indexes and queries? It's there a single index which will always grow and stored on disk or is the index split?
To spare someone a click, yes there is still a postgres server.<p>Can't stop being mad at the misuse of "serverless". Even worse than using crypto for cryptocurrencies. Words have meaning...