If you enjoyed watching this video, make sure to like and subscribe so you don't miss out on any future videos. How the driver works: - How the WebSocket version of the driver works: neon.tech/blog/serverless-driver-for-postgres - How we reduced the driver's latency by cutting network round-trips in half: neon.tech/blog/quicker-serverless-postgres#baseline-nine-round-trips-to-first-query-result - Performance of SQL-Over-HTTP: neon.tech/blog/sub-10ms-postgres-queries-for-vercel-edge-functions Try out Neon: neon.tech/youtube The Neon Serverless Driver: github.com/neondatabase/serverless
"Instead of TCP it offers HTTP and WebSockets" doesn't make sense. HTTP (unless you're talking HTTP/3) is basically always built on TCP as is the WebSocket protocol. It is also not clear to me, why adding additional complexity to fetching data from a database is actually useful here. As I see it, constructing a HTTP request or WebSocket payloads is way more resource intensive than just opening a TCP connection, especially since authentication and certificate checks still have to be done (twice actually, since the API has to do it for the incoming connection and then the Postgres Database has to do it again for the API). Curious to know if I'm missing some big advantage here.
In serverless environment, you can not open a TCP connection directly. That's the reason you need a HTTP approach. With normal PostgreSQL DB, you need to build a HTTP proxy to talk from serverless function to proxy then to DB. With Neon DB and this driver, you can skip the proxy
The basic reason for providing WebSocket and HTTP transport options is that some environments simply don't support raw TCP (e.g. Cloudflare Workers didn't at the time we released the driver, and Vercel Edge Functions still don't). More on this here: neon.tech/blog/serverless-driver-for-postgres In a serverless environment, you may need to reconnect with every web request, so we've done some work on the driver to speed up connections, which means they should be faster to establish than raw TCP connections, despite some additional overheads. We're continuing to work on reducing connection times. More on this here: neon.tech/blog/quicker-serverless-postgres
The basic reason for providing WebSocket and HTTP transport options is that some environments simply don't support raw TCP (e.g. Cloudflare Workers didn't at the time we released the driver, and Vercel Edge Functions still don't). More on this here: neon.tech/blog/serverless-driver-for-postgres
Pool and Client - in the edge environment doesn't make any difference let alone make any sense. Very confusing to use Pool - but not actually mean or get a Pool!! :( Why not EdgeClient? Clear in what it does and the mental model is gracefully guided to remember to close the connection.
The reason for using Pool and Client is for the driver to be fully compatible with node-postgres. >Why not EdgeClient? Clear in what it does and the mental model is gracefully guided to remember to close the connection I'll share your feedback with the team. Thank you so much for letting us know :)
If you enjoyed watching this video, make sure to like and subscribe so you don't miss out on any future videos.
How the driver works:
- How the WebSocket version of the driver works: neon.tech/blog/serverless-driver-for-postgres
- How we reduced the driver's latency by cutting network round-trips in half: neon.tech/blog/quicker-serverless-postgres#baseline-nine-round-trips-to-first-query-result
- Performance of SQL-Over-HTTP: neon.tech/blog/sub-10ms-postgres-queries-for-vercel-edge-functions
Try out Neon: neon.tech/youtube
The Neon Serverless Driver: github.com/neondatabase/serverless
"Instead of TCP it offers HTTP and WebSockets" doesn't make sense. HTTP (unless you're talking HTTP/3) is basically always built on TCP as is the WebSocket protocol. It is also not clear to me, why adding additional complexity to fetching data from a database is actually useful here. As I see it, constructing a HTTP request or WebSocket payloads is way more resource intensive than just opening a TCP connection, especially since authentication and certificate checks still have to be done (twice actually, since the API has to do it for the incoming connection and then the Postgres Database has to do it again for the API). Curious to know if I'm missing some big advantage here.
In serverless environment, you can not open a TCP connection directly. That's the reason you need a HTTP approach. With normal PostgreSQL DB, you need to build a HTTP proxy to talk from serverless function to proxy then to DB. With Neon DB and this driver, you can skip the proxy
The basic reason for providing WebSocket and HTTP transport options is that some environments simply don't support raw TCP (e.g. Cloudflare Workers didn't at the time we released the driver, and Vercel Edge Functions still don't). More on this here: neon.tech/blog/serverless-driver-for-postgres
In a serverless environment, you may need to reconnect with every web request, so we've done some work on the driver to speed up connections, which means they should be faster to establish than raw TCP connections, despite some additional overheads. We're continuing to work on reducing connection times. More on this here: neon.tech/blog/quicker-serverless-postgres
Great in Deno Deploy this configuration also works very fast 👌
Kudos on the thumbnail
Why would a http/websocket connection be better than just a direct TCP connection?
The basic reason for providing WebSocket and HTTP transport options is that some environments simply don't support raw TCP (e.g. Cloudflare Workers didn't at the time we released the driver, and Vercel Edge Functions still don't). More on this here: neon.tech/blog/serverless-driver-for-postgres
Pool and Client - in the edge environment doesn't make any difference let alone make any sense. Very confusing to use Pool - but not actually mean or get a Pool!! :( Why not EdgeClient? Clear in what it does and the mental model is gracefully guided to remember to close the connection.
The reason for using Pool and Client is for the driver to be fully compatible with node-postgres.
>Why not EdgeClient? Clear in what it does and the mental model is gracefully guided to remember to close the connection
I'll share your feedback with the team. Thank you so much for letting us know :)
This was absolutely boring, lol
JS devs are probably dying of boredom.