4 ms·

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

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.

raoufchebri 3y ago
We use a proxy that redirects the request to the compute node. The proxy uses WebSockets in this case. https://neon.tech/blog/serverless-driver-for-postgres https://neon.tech/blog/serverless-driver-for-postgres
gmac 3y ago
Every connection to a Neon database (traditional TCP, WebSockets, https) now goes via the same custom (open-source) proxy server that's close to the database compute node. So there's technically an additional hop irrespective of the transport type, but not one that should add meaningfully to the latency, or that would make WebSockets slower than the others.
- deleted 3y ago
  [deleted]
bob1029 3y ago
The diagram is confusing me too. We are using Az Functions to serve webapps via HTTP triggers and they just take a direct connection to SQL. Our average trip to the database is ~5 milliseconds for the trivial views. No web sockets, middleware, etc. What value is added with this extra middleware/ceremony/etc?
- gmac 3y ago
  Right. If TCP is available, any common-or-garden Postgres driver will do (for Neon or any other Postgres DB). But not all serverless compute environments support TCP connections.
- mwcampbell 3y ago
  > Our average trip to the database is ~5 milliseconds Do you miss the performance that you had when the DB was running inside the application process using SQLite? Are you at all sad that you had to give that up in order to outsource compliance to Azure?
  - bob1029 3y ago
    > Are you at all sad that you had to give that up in order to outsource compliance to Azure? A little bit, but it's honestly much better this way in our use case. For our specific business & application, going from 50uS to 5000uS feels like nothing. We were squandering 2+ orders of magnitude over JSON blobs in columns anyways. We really didn't need 50uS transactions for anything. What turned out to be far more important was one source of truth to worry about. We have a lot of installs and a lot of SQLite databases out there. Now we are looking at exactly one for the whole enterprise. Moving to hosted DB forced cleaner schema design. No json blobs = law now because of IO scaling concerns. We can't afford to move 5 megabytes of JSON across the datacenter every time someone clicks a button anymore. Average per-user-action database hit has fallen by 4~5 orders of magnitude. Megabytes to hundreds of bytes. Overall perceived performance is actually much better because of these design constraints. We also try to get the web views composed using as few queries as possible (i.e. finally make the database do its damn job instead of lazily peddling JSON).

raoufchebri 3y ago

We use a proxy that redirects the request to the compute node. The proxy uses WebSockets in this case. https://neon.tech/blog/serverless-driver-for-postgres https://neon.tech/blog/serverless-driver-for-postgres

gmac 3y ago

Every connection to a Neon database (traditional TCP, WebSockets, https) now goes via the same custom (open-source) proxy server that's close to the database compute node. So there's technically an additional hop irrespective of the transport type, but not one that should add meaningfully to the latency, or that would make WebSockets slower than the others.

deleted 3y ago
[deleted]

bob1029 3y ago

The diagram is confusing me too. We are using Az Functions to serve webapps via HTTP triggers and they just take a direct connection to SQL. Our average trip to the database is ~5 milliseconds for the trivial views. No web sockets, middleware, etc. What value is added with this extra middleware/ceremony/etc?

gmac 3y ago
Right. If TCP is available, any common-or-garden Postgres driver will do (for Neon or any other Postgres DB). But not all serverless compute environments support TCP connections.
mwcampbell 3y ago
> Our average trip to the database is ~5 milliseconds Do you miss the performance that you had when the DB was running inside the application process using SQLite? Are you at all sad that you had to give that up in order to outsource compliance to Azure?
- bob1029 3y ago
  > Are you at all sad that you had to give that up in order to outsource compliance to Azure? A little bit, but it's honestly much better this way in our use case. For our specific business & application, going from 50uS to 5000uS feels like nothing. We were squandering 2+ orders of magnitude over JSON blobs in columns anyways. We really didn't need 50uS transactions for anything. What turned out to be far more important was one source of truth to worry about. We have a lot of installs and a lot of SQLite databases out there. Now we are looking at exactly one for the whole enterprise. Moving to hosted DB forced cleaner schema design. No json blobs = law now because of IO scaling concerns. We can't afford to move 5 megabytes of JSON across the datacenter every time someone clicks a button anymore. Average per-user-action database hit has fallen by 4~5 orders of magnitude. Megabytes to hundreds of bytes. Overall perceived performance is actually much better because of these design constraints. We also try to get the web views composed using as few queries as possible (i.e. finally make the database do its damn job instead of lazily peddling JSON).