5 ms·

Author here; SQL Proxies definitely are a relevant use case. Also low latency scenarios, where you want to have the (query) capabilities and semantics of Postgr

Author here; SQL Proxies definitely are a relevant use case. Also low latency scenarios, where you want to have the (query) capabilities and semantics of Postgres instead of an in-memory or embedded database. Depending on the workload, the advantage over TCP is signficant (see links in the post).

lmilcin 6y ago
You mean SQL Proxy available on the VM/container where the application runs and application connecting locally to the proxy? I can see how it sometimes may make the application simpler and maybe, potentially, how you can have single proxy to serve multiple tenants (containers with applications) so that they maybe don't have to keep their own pools of connections. The services would talk to each other locally and use the proxy to talk to the database using single connection pool. But I don't see how this couldn't be as effective with TCP loopback (which actually is hacked to not invoke any TCP). Granted, domain sockets are bit faster than localhost (https://redis.io/topics/benchmarks https://redis.io/topics/benchmarks) but if this makes difference for your application you are likely using wrong architecture.
- _red 6y ago
  There are other benefits. UDS can be permissioned using standard unix USER/GROUP which adds more flexible security structure (more so when you combine UDS with SE Linux). This is opposed to localhost which is much harder to firewall from-localhost->to-localhost
  - lmilcin 6y ago
    I don't exactly see that as any better security. The assumption nowadays is that once something breached application safeties and has user level access to a machine it is as if it had root level access to that machine. The reason is that there is just too much surface between an application and the operating system to be able to guarantee safety. And so we put applications into their separate VMs or containers and treat the entire container as part of the application. There are no other assets on that container.
    - toast0 6y ago
      If the container boundary is meaningful, you can do things like run TLS termination in a container (because OpenSSL is a quagmire), and connect to the server via unix socket. Then the container has no need for outgoing network sockets, and limited filesystem access. Of course, if the container boundary isn't meaningful, you've complicated your system design for nothing. And either way, TLS termination in a separate process is a potentially significant penalty to performance, as you'll have a lot more copies.
xxs 6y ago
>Also low latency scenarios Low latency (e.g. HFT) = no database at all, esp. not on the fast paths. Mostly direct buffers for everything, including interprocess communication via file mapped memory.
- deleted 6y ago
  [deleted]

lmilcin 6y ago

You mean SQL Proxy available on the VM/container where the application runs and application connecting locally to the proxy? I can see how it sometimes may make the application simpler and maybe, potentially, how you can have single proxy to serve multiple tenants (containers with applications) so that they maybe don't have to keep their own pools of connections. The services would talk to each other locally and use the proxy to talk to the database using single connection pool. But I don't see how this couldn't be as effective with TCP loopback (which actually is hacked to not invoke any TCP). Granted, domain sockets are bit faster than localhost (https://redis.io/topics/benchmarks https://redis.io/topics/benchmarks) but if this makes difference for your application you are likely using wrong architecture.

_red 6y ago
There are other benefits. UDS can be permissioned using standard unix USER/GROUP which adds more flexible security structure (more so when you combine UDS with SE Linux). This is opposed to localhost which is much harder to firewall from-localhost->to-localhost
- lmilcin 6y ago
  I don't exactly see that as any better security. The assumption nowadays is that once something breached application safeties and has user level access to a machine it is as if it had root level access to that machine. The reason is that there is just too much surface between an application and the operating system to be able to guarantee safety. And so we put applications into their separate VMs or containers and treat the entire container as part of the application. There are no other assets on that container.
  - toast0 6y ago
    If the container boundary is meaningful, you can do things like run TLS termination in a container (because OpenSSL is a quagmire), and connect to the server via unix socket. Then the container has no need for outgoing network sockets, and limited filesystem access. Of course, if the container boundary isn't meaningful, you've complicated your system design for nothing. And either way, TLS termination in a separate process is a potentially significant penalty to performance, as you'll have a lot more copies.

xxs 6y ago

>Also low latency scenarios Low latency (e.g. HFT) = no database at all, esp. not on the fast paths. Mostly direct buffers for everything, including interprocess communication via file mapped memory.

deleted 6y ago
[deleted]