kernel asynchronous reads in PostgreSQL 19 (io_uring)
18 points by rrampage
18 points by rrampage
interesting, thank you for posting. I always thought that 'friends do not let friends to run a db engine in a container'. I did not realize that io_ring is disabled in docker containers (was not not the main focus of the article though)
Running DB containers is quite popular, what do you mean by this?
Aren’t containers meant to be somewhat ephemeral? Isn’t running a db in a container somewhat of an anti pattern?
The containers are ephemeral but you can give them access to long-lived storage via volumes. So your container's root filesystem gets thrown away whenever the container dies, but /var/lib/postgresql is mounted in as a persistent volume. That's how it's usually done, anyway.
Whether this is an anti-pattern is up to you. I will say I don't hate it.
Interesting, do you happen to know if there’s a performance implication for doing this?
Too hard to say in general, I think. It depends on too many factors.
In a common setup, your container's / will be an overlayfs, backed by several immutable layers and adding ephemeral mutability on top. This means you get efficient deduplication and cleanup but tends to be somewhat slower than a regular filesystem, especially for directory traversal. The volume for your DB storage would be a more traditional fs like ext4 or XFS with its usual performance characteristics. But you can set this up in many other ways too.
in long past, and I mean about 2015-2016, I understood that the container isolation was not enough to keep IO performance/contention for interrupts (disk interrupts/network interrupts) isolated. So if a server runs say 10 database containers, the performance of each database would be less optimal than running 10 separate VMs on the same server, under the same load.
I will admit that by now I do not recall how I came across this opinion. .. but that's what I meant in the above