pg_qos añade límites de CPU, memoria y consultas por base de datos en un Postgres compartido
La extensión permite acotar el consumo de cada aplicación dentro de la misma instancia, sin migrar a servidores separados ni reiniciar los servicios conectados.
Cualquiera que comparta una instancia de PostgreSQL entre varios servicios conoce el patrón. Todo funciona bien hasta que uno de ellos lanza un job pesado y el resto se arrastra. pg_qos es una extensión que mete límites por base de datos y por rol dentro del mismo servidor, sin sacar cada aplicación a su propio Postgres ni montar un pooler por servicio.
La configuración se hace con ALTER DATABASE y ALTER ROLE, lo que significa que las reglas viven en el catálogo y se pueden aplicar con la misma mecánica que ya usa un administrador para tocar parámetros de una base concreta:
ALTER DATABASE immich SET qos.cpu_core_limit = '2';
ALTER DATABASE nextcloud SET qos.max_concurrent_select = '20';
ALTER ROLE gitea SET qos.work_mem_limit = '64MB';
Los límites que cubre son cuatro: núcleos de CPU, que solo funciona en Linux; número de consultas y transacciones simultáneas; consultas por segundo, con formatos como '100/1s'; y memoria por sesión a través de work_mem. Los cambios se aplican sobre sesiones que ya están conectadas, así que no hace falta reiniciar Nextcloud, Gitea ni nada de lo que esté colgando de la instancia.
El proyecto soporta PostgreSQL 15 a 18, publica paquetes .deb y .rpm para Debian 13, Ubuntu 24.04 y RHEL 10, y va bajo GPL-3.0. El código está en el repositorio appstonia/pg_qos.
Lo que el anuncio no trae
El detalle importante es de dónde sale esto. Lo publica su propio autor en r/selfhosted, no hay benchmark independiente ni comparativa contra las alternativas que ya existen para el mismo problema: poner un pooler delante, limitar con cgroups, o directamente separar instancias. Tampoco explica cómo implementa por dentro el tope de CPU más allá de que requiere Linux.
Los cuatro parámetros que enseña son razonables para el caso que describe, pero ahí se acaba la evidencia. Quien tenga pensado desplegarlo en producción debería probarlo antes con carga real en su escenario, sobre todo cuando varios servicios coinciden en picos.
La extensión es útil de verdad si el problema es ese exacto: una instancia compartida entre aplicaciones de peso desigual y con equipo pequeño. Si ya tienes aislamiento por contenedor o instancias separadas, no aporta gran cosa. Un vistazo a la implementación y a las pruebas que hagan los primeros usuarios aclarará si los límites se cumplen bajo presión o solo quedan bien en la documentación.
