Implementar multitenancy con miles de bases de datos en un solo servidor
Una comunidad de sysadmins pregunta cómo gestionar miles de bases de datos aisladas sin recurrir a varios servidores.
En una publicación reciente de r/selfhosted, un administrador plantea la cuestión de si es posible alojar miles de bases de datos en un solo servidor, utilizando tecnologías como Neon, MySQL y otras. El objetivo no es la réplica entre nodos, sino el aislamiento multitenant: cada cliente tendría su propia base de datos independiente.
El reto principal es la gestión de recursos. Con MySQL, por ejemplo, cada base consume memoria para buffers y logs. Si se crean 5 000 bases, el consumo puede superar los límites de RAM del host. Una solución común es limitar la cantidad de conexiones simultáneas y usar contenedores ligeros (p. ej., Docker) para encapsular cada base. Otra opción es la database‑as‑a‑service interna, donde un gestor de bases de datos (pgbouncer, ProxySQL) enruta peticiones al esquema correcto.
Neon, por su parte, ofrece una arquitectura serverless que permite escalar sin preocuparse por la infraestructura física. Cada base de datos se ejecuta en un contenedor aislado dentro de la capa de Neon, y el coste de recursos se distribuye dinámicamente. Para MySQL, el uso de innodb_buffer_pool_size por base puede ajustarse con variables de sesión, reduciendo la huella.
Otro aspecto es la seguridad. Cuando se comparten servidores, las fugas de datos son un riesgo. Es recomendable usar namespace de Kubernetes con políticas de red estrictas, y aplicar row‑level security a nivel de base. El uso de pg_hba.conf y my.cnf con reglas específicas por usuario evita que un cliente acceda a otro.
El rendimiento también se ve afectado por la fragmentación del disco y el I/O. Los SSD modernos mitigaron gran parte de este problema, pero el file‑system debe estar optimizado para un alto número de archivos. El uso de xfs o ext4 con opciones de journaling reducen la latencia.
Para monitorizar el estado de cada base, herramientas como Prometheus con exporters de MySQL o pg_stat_activity para PostgreSQL permiten observar el uso de CPU, memoria y I/O por base. Los dashboards de Grafana pueden agrupar métricas por cliente, facilitando la detección de anomalías.
En cuanto a licencias, Neon es de código abierto bajo la licencia Apache 2.0, mientras que MySQL se distribuye bajo GPL con opciones comerciales. Si el objetivo es mantener todo bajo una única licencia, PostgreSQL (con licencia PostgreSQL) podría ser una alternativa viable.
El último punto a considerar es la política de respaldo. Con miles de bases, los backups tradicionales se vuelven ineficientes. Soluciones como wal‑archive en PostgreSQL o binlog‑dump en MySQL permiten respaldos incrementales a nivel de base, reduciendo el tiempo de inactividad.
En resumen, alojar miles de bases de datos en un solo servidor es factible si se planifica la arquitectura desde el principio: limitación de recursos, contenedores, políticas de seguridad, monitorización y backups eficientes. La elección entre Neon, MySQL o PostgreSQL dependerá de los requisitos de licencia, rendimiento y compatibilidad de tu stack.
Repost del hilo original
