Calculadora de conexiones máximas

Cuántas conexiones te dará realmente una base de datos gestionada

Toda base de datos gestionada tiene un techo de conexiones, y ninguna de las tres grandes nubes lo fija igual. AWS lo deriva de una fórmula sobre la memoria de la instancia, Azure publica una tabla fija por producto y Google Cloud SQL usa tramos de memoria que suben a saltos. Esta herramienta aplica la regla publicada por cada proveedor para que veas el techo real antes de diseñar un pool sobre una suposición.

Cómo funciona

• Aplica la regla documentada del proveedor a la instancia que elijas, no una regla general.
• Muestra juntos el resultado de la fórmula y el resultado realista, porque DBInstanceClassMemory es menor que la RAM de la instancia.
• Compara las tres nubes con la misma memoria, que es donde las diferencias se vuelven imposibles de ignorar.
• Resta las conexiones que Azure reserva para replicación y monitorización, de modo que la cifra mostrada es la que puede usar tu aplicación.

AWS RDS, según los parámetros por defecto documentados
  PostgreSQL   LEAST({DBInstanceClassMemory/9531392}, 5000)
  MySQL        {DBInstanceClassMemory/12582880}
  MariaDB 10.5+ LEAST({DBInstanceClassMemory/25165760}, 12000)

Azure Flexible Server
  una tabla publicada por producto, unas 107 por GiB, con tope de 5000
  menos 15 reservadas para replicación y monitorización

Google Cloud SQL
  tramos de memoria publicados, límite inferior incluido
  3,75-6 GiB -> 100   6-7,5 -> 200    7,5-15 -> 400
  15-30      -> 500  30-60  -> 600   60-120 -> 800
  120+       -> 1000

Ejemplo resuelto

Una db.r7g.xlarge con PostgreSQL — 4 vCPU y 32 GiB de memoria — y qué compran esos mismos 32 GiB en otro sitio.

1. 32 GiB = 34.359.738.368 bytes
2. 34.359.738.368 / 9.531.392 = 3.604 — la respuesta de la fórmula
3. el tope de 5.000 no actúa a este tamaño, así que se queda en 3.604
4. pero DBInstanceClassMemory no es la RAM de la instancia: RDS resta primero el sistema y sus propios procesos
5. aplicando la sobrecarga que AWS documenta salen unas 3.324 en la práctica
6. Azure con 32 GiB: 3.437 en total, 3.422 utilizables tras las 15 reservadas
7. Google Cloud SQL con 32 GiB: 600, porque 32 cae en el tramo de 30 a 60 GiB

Hardware idéntico, y Cloud SQL te da una quinta parte de lo que dan las otras dos. Si mueves un servicio entre nubes, esta única cifra tiene más probabilidades de romper la migración que cualquier cosa de tu esquema.

Cómo leer el resultado

• DBInstanceClassMemory no es la memoria de la ficha de la instancia. RDS reserva memoria para el sistema operativo y sus propios procesos de gestión y calcula la fórmula sobre lo que queda. AWS documenta la diferencia con un ejemplo: una instancia de 8 GiB da unas 630 conexiones donde la división ingenua da 683. Es en torno a un 8% menos, y ocurre en todos los tamaños.
• Google Cloud SQL usa tramos publicados en lugar de una fórmula, así que el límite no sube de forma continua con la memoria: dentro de un tramo no sube en absoluto. Toda instancia desde 30 GiB hasta justo por debajo de 60 GiB obtiene las mismas 600 conexiones, así que duplicar la memoria dentro de un tramo no compra nada y todo el aumento cae en el límite del tramo.
• Azure trata B1ms como caso especial con 50 conexiones, fuera del patrón por GiB que por lo demás es consistente. Por eso esta herramienta reproduce la tabla de Azure literalmente en lugar de ajustarle una recta.
• Son valores por defecto, no límites duros. max_connections es un parámetro modificable en las tres nubes. Subirlo suele ser el arreglo equivocado, porque cada conexión cuesta memoria y un proceso — la razón misma de que el valor por defecto dependa de la memoria.
• Un límite de conexiones no es un objetivo de concurrencia. Postgres no va más rápido según suben las conexiones; pasadas unas pocas veces el número de núcleos, más conexiones significan más cambios de contexto y menos rendimiento. Usa un pooler y mantén el pool bastante por debajo del techo.

Preguntas frecuentes

¿Por qué mi instancia informa un max_connections distinto?

Tres motivos habituales. El grupo de parámetros puede haberse modificado, y entonces tu valor sustituye por completo a la fórmula. La versión del motor importa: MariaDB cambió su divisor en la 10.5. Y en AWS la cifra se mueve algo según la memoria exacta que informa el host, por eso esta herramienta muestra ambos valores.

¿Debería simplemente subir max_connections?

Normalmente no. Cada conexión de PostgreSQL es un proceso con su propia memoria, y cada conexión de MySQL lleva búferes por hilo. Subir el techo traslada el fallo desde conexiones rechazadas, que son visibles y recuperables, hasta presión de memoria y el OOM killer, que no son ni lo uno ni lo otro. Un pool de conexiones casi siempre es la mejor respuesta.

¿Una réplica de lectura tiene el mismo límite?

Tiene el de su propia clase de instancia, a menudo el mismo porque las réplicas suelen igualar a la principal. Pero sus conexiones se cuentan aparte, así que dirigir lecturas a una réplica gana margen real en la principal en vez de solo mover el problema.

¿Por qué Cloud SQL está tan por debajo?

Google dimensiona el valor por defecto según lo que la instancia sirve bien, no según lo que técnicamente acepta, y da por hecho que las cargas con muchas conexiones van detrás de un pooler. Es una decisión de diseño, no una restricción del hardware — pero se aplica igualmente, así que te limita de todos modos.

Fuentes

• Amazon RDS — cuotas y restricciones
• Amazon RDS — clases de instancia de base de datos
• Azure Database for PostgreSQL — límites
• Cloud SQL para PostgreSQL — marcas