>it can use localhost which is realistically as efficient as domain socket but is more flexible.

Actually, Unix domain sockets are substantially more flexible than localhost. For exampe, Unix domain sockets have filesystem-based access controls, they can have meaningful paths instead of magic numbers, and they are trivially used across different containers (just bind mount the socket file in to whatever container, just like any other file).

> Unix domain sockets have filesystem-based access controls

This is dependent on the operating system. The Linux kernel obeys access permissions on the file inode, but Solaris doesn't. (I always forget how AIX, macOS, FreeBSD, NetBSD, and OpenBSD behave.) But even on Linux there's the classic race condition if your umask isn't set correctly when you invoke bind. Interestingly, on Linux you can fchmod the descriptor before calling bind, which is better than temporarily changing the umask around bind as it's not thread friendly--the umask is global so would effect whatever files are being opened in other threads at that moment.

But you don't need to rely on the permissions of the socket file inode itself. You can just create a directory with the restrictive permissions and then bind the socket into that directory. That's perfectly portable, presumably even to Windows, and also avoids umask races. In fact, using directories this way is almost always the superior option (e.g. for temporary files, etc), though it's a tad more leg work so unfortunately people rarely use that pattern.

But all Unix systems also support querying credentials over Unix domain sockets, where "credentials" basically means the UID and GID of the peer[1], which permits supporting user- or group-based authentication without passwords. I'm pretty sure Postgres supports this; that is, you can configure Postgres to allow user foo to access DB bar without a password, token, or signed cert. I submitted a patch many years ago so this would work on OpenBSD. (At the time OpenBSD provided getpeereid for querying peer credentials, but Postgres only supported SO_PEERCRED and some other mechanisms. Years later OpenBSD eventually adopted the SO_PEERCRED approach, which is what Linux uses, and made getpeereid a wrapper, because sometimes it's not worth swimming upstream. None of these are defined by POSIX but the capability is supported one way or another on all the extant Unix systems.)

[1] Depending on the OS, credentials can include other information, like PID.

well, X11's abstract sockets try to disagree about the access-control part

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).

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) but if this makes difference for your application you are likely using wrong architecture.

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

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.

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.

>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.

> localhost which is realistically as efficient as domain socket

That depends on your platform. FreeBSD actually runs localhost as tcp, and you can have delays, packet loss when the buffer is full, and congestion collapse on localhost. It's lots of fun, but if I asked for tcp and got tcp, I'm not terribly surprised. It's not like BSD hasn't had a better option for local sockets since forever (did unix domain sockets ship at the same time as tcp? I don't know, but they both shipped before I had a computer at home), so my fault for choosing poorly or using a language that doesn't support nice things.

localhost is slower than Unix sockets on Linux as well. Try a benchmark with Redis or KeyDB and the performance differences are clear.

I've also found Unix domain sockets useful when wiring together services in CI or testing environments. In such situations, performance is important but all services are known to be running on the same machine.