Respuesta: Cómo calcular la capacidad de la base de datos
Si te preguntas cómo calcular la capacidad de almacenamiento, la fórmula práctica es: medir el tamaño actual en GB, añadir un multiplicador realista para índices y sobrecarga del motor, proyectar el crecimiento diario durante tu ventana de retención, y luego multiplicar por los factores de replicación y espacio libre. Demasiados equipos se detienen en cómo se calcula la capacidad de almacenamiento como si fuera solo contar filas por el ancho de las columnas. En mi primer gran esfuerzo de dimensionamiento para un pipeline de registros PostgreSQL, cometí exactamente ese error: estimé 120 GB de JSON crudo, ignoré la hinchazón de los índices y una réplica en espera, y alcanzamos presión de disco en 11 semanas en lugar de los 9 meses proyectados. Esta guía te ofrece el recorrido agnóstico de bases de datos que desearía haber tenido: SQL para verificar el tamaño de la BD en GB, una plantilla de pronóstico, y los límites no relacionados con almacenamiento que realmente causan interrupciones.
La capacidad no es un número único; es un compuesto de techos de almacenamiento, conexiones y rendimiento. El marco a continuación funciona para PostgreSQL, MySQL, SQL Server y Oracle con pequeños cambios de SQL. También encontrarás un enlace a nuestra Calculadora de Capacidad de Base de Datos interactiva que automatiza las matemáticas.
Paso 1: Verifica el tamaño actual de tu base de datos en GB (en todos los motores)
La consulta más común es cómo verificar el tamaño de la BD en GB. La respuesta es SQL específico del motor, pero la lógica de conversión es universal: recuperar bytes asignados de los catálogos del sistema y luego dividir por la potencia apropiada de 1024 o 1000.
PostgreSQL: pg_database_size
Ejecuta lo siguiente en psql o cualquier cliente:
SELECT round(pg_database_size('app_prod')/1024.0/1024.0/1024.0, 2) AS size_gb;
Esto devuelve gigabytes binarios (GiB). La función tiene en cuenta tablas, índices y archivos de mapa de visibilidad. Siempre redondeo a dos decimales para evitar falsa precisión. Para el comportamiento oficial, consulta la documentación de PostgreSQL.
MySQL: Suma de information_schema
MySQL carece de una función de tamaño única, así que suma las longitudes de datos e índices por esquema:
SELECT round(SUM(data_length+index_length)/1024/1024/1024, 2) AS size_gb FROM information_schema.tables WHERE table_schema='app_prod';
Esto excluye los registros de deshacer y los registros binarios, que pueden ser sustanciales. El manual de referencia de MySQL señala que estas columnas son aproximaciones para InnoDB.
SQL Server y Oracle: Resumen rápido
En SQL Server, EXEC sp_spaceused devuelve database_size en MB; divide por 1024. La suma de DBA_SEGMENTS de Oracle por bytes da la asignación a nivel de bloque. El principio sigue siendo: confía en el catálogo del propio motor sobre el du del sistema de archivos porque los archivos dispersos engañan.
¿Cómo se calculan los GB? Binario vs decimal
Aquí está el detalle que sesga los pronósticos: ¿cómo se calculan los GB a partir de bytes? Los proveedores de almacenamiento y las facturas de la nube usan decimal (1 GB = 1,000,000,000 bytes), mientras que las bases de datos devuelven binario (1 GiB = 1,073,741,824 bytes). Esa brecha del 7.4% parece pequeña hasta que pronosticas 5 TB—entonces son 374 GB de espacio «faltante». Estandarizo en GiB internamente pero reporto GB decimal a finanzas para coincidir con las facturas de AWS.
Al principio de mi carrera, un equipo de finanzas presupuestó 10 TB de almacenamiento SAN basado en mi informe de GB decimal, pero el equipo de DBA aprovisionó volúmenes de 10 TiB (binarios). La brecha del 10% apareció como una compra de emergencia de $40k. Desde entonces, etiqueto las unidades explícitamente: GiB para tecnología, GB para adquisiciones.
Otro caso límite: una fila eliminada en PostgreSQL no se recupera hasta VACUUM; pg_database_size incluye tuplas muertas. InnoDB puede no encoger los archivos ibd después de eliminaciones. Siempre combina verificaciones de tamaño con consultas de hinchazón antes de pronosticar.
Paso 2: Descompón los componentes de almacenamiento y aplica multiplicadores de sobrecarga
Cuando un CTO pregunta cómo se calcula la capacidad de almacenamiento, generalmente se refiere a datos de tabla crudos. La capacidad real incluye índices, registros de escritura anticipada, replicación y margen libre. La tabla a continuación es el modelo de multiplicador que he refinado en seis migraciones de producción.
| Componente | Multiplicador típico | Cuándo aumenta |
|---|---|---|
| Datos de tabla base | 1.0× | Siempre presente |
| Índices B-tree secundarios | 0.5×–1.5× | Alta cardinalidad, claves UUID |
| Índices GIN / texto completo | 1.0×–2.5× | Columnas de matriz o búsqueda de texto |
| WAL / redo / undo | 0.1×–0.3× del cambio diario | Transacciones largas, retraso de replicación |
| Factor de replicación | 2×–3× | En espera, multi-región |
| Margen de espacio libre | 20%–30% | Autovacuum, desfragmentación, picos |
La mayoría no se da cuenta de que bajo cargas pesadas de UPDATE/DELETE, la hinchazón de índices PostgreSQL puede empujar el multiplicador de índice más allá de 2.5×. Una vez audité una tabla de 40 GB con 160 GB de índices porque una clave externa faltante causó cascadas por fila y divisiones de página.
Lo que nadie te dice sobre las matemáticas de almacenamiento: el tamaño de tu índice es una función de tu patrón de escritura, no solo de tu recuento de filas. Mide la hinchazón con
pgstattupleantes de confiar en cualquier estimación.
Replicación: Síncrona vs asíncrona
La replicación síncrona escribe en la réplica antes de confirmar, duplicando la E/S de escritura pero no necesariamente duplicando los bytes almacenados si la réplica comparte una instantánea. La réplica asíncrona aún almacena una copia completa, así que el factor de replicación se mantiene. Pero las réplicas en cascada pueden reducir el factor; he usado una cadena de 1 primario-2 réplicas con solo 2.2× de almacenamiento total en lugar de 3×.
Concepto erróneo común: «Recuento de filas × ancho de columna»
Los principiantes calculan la capacidad como filas × suma(bytes_columna). Eso ignora la compresión NULL, el relleno de alineación y la sobrecarga de página (encabezado de montón de 24 bytes por fila en Postgres). En una tabla con 20 columnas booleanas anulables, el almacenamiento real puede ser 40% menos que las matemáticas ingenuas—o 30% más si usas claves primarias uuid anchas con inserción aleatoria que causa fragmentación. La experiencia significa saber cuándo falla el atajo.
Paso 3: Pronostica la capacidad futura con una fórmula repetible
Para responder cómo calculo la capacidad para el próximo trimestre, usa esta plantilla: GB_futuros = (GB_actuales × Multiplicador_sobrecarga) + (Crecimiento_diario × Días_retención) × Factor_replicación. No es lineal; el crecimiento exponencial necesita modelado compuesto.
Ejemplo trabajado con números reales
Supongamos que el tamaño medido actual es 50 GiB, el multiplicador de sobrecarga es 1.6, el crecimiento diario es 0.4 GiB, la retención es 120 días, y el factor de replicación es 2. Cálculo: (50×1.6) + (0.4×120) = 80 + 48 = 128 GiB; ×2 = 256 GiB. Agrega 25% de espacio libre => 320 GiB necesarios. Ese es el número a aprovisionar, no 50.
Para omitir las matemáticas manuales, nuestra Calculadora de Capacidad de Base de Datos codifica esto con controles deslizantes para replicación y compresión. Mantengo una versión de hoja de cálculo para auditorías porque muestra el linaje de la fórmula a las partes interesadas.
Retención variable y retenciones legales
La retención no siempre es un solo número. Un cliente SaaS almacenó 30 días de datos en vivo pero 7 años de facturas archivadas en una tabla en frío. Dividí la fórmula: la capacidad en caliente usa el crecimiento de 30 días; la capacidad en frío es un bloque único de 1.2 TB con crecimiento cero. Si los mezclas, sobredimensionarás el almacenamiento en caliente y malgastarás dinero.
Ejemplo con compresión habilitada
Si el mismo conjunto de datos de 50 GiB usa compresión ZFS 3× en los datos de la tabla pero los índices permanecen iguales, la base efectiva cambia. La sobrecarga original de 1.6 incluía el índice. La compresión puede reducir la tabla a la mitad, la nueva sobrecarga es ~1.3. Lo introduzco en la calculadora para evitar errores manuales y recalculo la replicación sobre la cifra reducida.
Cuando la previsión lineal falla
Si el número de usuarios se duplica cada período, usa la fórmula compuesta Actual × (1 + tasa_diaria)^días. Pero cuidado: la mayoría de las startups sobreestiman la linealidad; he visto cómo la deserción aplana el crecimiento después del mes 3. Valida con 4 semanas de tasas reales de ingesta antes de comprometer capital.
Paso 4: Planifica los límites no relacionados con almacenamiento: conexiones, IOPS y rendimiento
Lo que nadie te dice sobre la capacidad de una base de datos: el almacenamiento es el límite más fácil de expandir; el agotamiento de conexiones y CPU tumbarán tu aplicación mientras el disco está a la mitad. Al planificar la capacidad, trata max_connections y la latencia de consultas como restricciones de primera clase.
Matemáticas del pool de conexiones
Si tu aplicación usa 200 instancias de microservicios × 10 conexiones cada una, eso son 2,000 conexiones potenciales. PostgreSQL tiene 100 por defecto. Necesitas PgBouncer o un proxy gestionado. Estima las consultas concurrentes activas como (número_de_núcleos × 2) para OLTP. Para pruebas de carga, nuestra Calculadora de capacidad de carga ayuda a modelar los límites de solicitudes concurrentes antes de alcanzar FATAL: remaining connection slots are reserved.
Una tormenta de conexiones real
Durante un despliegue de Kubernetes, 300 pods abrieron cada uno 20 conexiones antes de que la sonda de preparación tuviera éxito, explotando a 6,000 intentos. El pooler nos salvó, pero solo porque habíamos configurado max_client_conn correctamente. La planificación de capacidad debe incluir ráfagas en modo de fallo, no solo el estado estable.
IOPS y rendimiento de almacenamiento
Los volúmenes en la nube limitan las IOPS; un SSD de 200 GiB puede tener un tope de 3,000 IOPS. Si tu carga de escritura necesita 5,000, estás limitado por capacidad a pesar de tener GB libres. Mide con pg_stat_io o sys.dm_io_virtual_file_stats. He visto una base de datos de 100 GiB incapaz de manejar el Black Friday por un techo de 1,000 IOPS, no por espacio.
La memoria como dimensión de capacidad
El buffer pool o shared_buffers deben contener tu conjunto de trabajo. Si los datos activos superan la RAM, golpearás el disco. Una regla aproximada: dimensiona la memoria al 25%–40% del conjunto de datos en caliente. Por eso la capacidad no es solo «cuántos GB en disco».
Paso 5: La lista de verificación unificada de capacidad de base de datos y la matriz de decisión
Destilé lo anterior en una lista de verificación de 7 puntos utilizada en mis últimas tres migraciones:
- 1. Mide el tamaño actual en GB/GiB mediante SQL del motor (Paso 1).
- 2. Identifica la hinchazón de tablas/índices con pgstattuple o estadísticas de InnoDB.
- 3. Aplica el multiplicador de sobrecarga de la tabla anterior.
- 4. Registra el crecimiento diario promedio de 14 días, no una suposición.
- 5. Multiplica por las necesidades de replicación y retención.
- 6. Añade un 25% de espacio libre como margen para autovacuum/desfragmentación.
- 7. Verifica el pool de conexiones y el margen de IOPS.
Matriz de decisión para escalar
Más allá de la lista de verificación, usa esta matriz: si el tamaño previsto > 70% del límite de volumen actual pero el margen de IOPS > 40%, escala solo el almacenamiento. Si la saturación de conexiones > 80%, añade una réplica de lectura o un pooler antes de añadir disco. Para una previsión de 400 GiB en un volumen de 512 GiB con un 70% de IOPS usadas, escala el almacenamiento a 1 TB pero mantén la computación. Este enfoque matizado evita gastos innecesarios.
El marco es agnóstico respecto a la base de datos; cambia el SQL del paso 1 y mantén el resto. Une consejos fragmentados y documentación empresarial con precisión.
Errores comunes que he cometido para que tú no tengas que hacerlo
Cuando intenté dimensionar una base de datos para una aplicación de salud por primera vez, confié en el documento técnico del proveedor sobre «tamaño promedio de fila». Las filas reales eran 3× más grandes debido al JSON incrustado. Error uno: nunca confíes en los promedios del proveedor sin muestrear tus propios datos.
Error dos: ignorar los picos estacionales. El Black Friday de un cliente minorista arrojó 10× el crecimiento diario durante 3 días; la fórmula lineal lo pasó por alto. Ahora añado un margen de picos del 15% para cualquier sistema orientado al consumidor.
Error tres: olvidar que eliminar datos no libera disco inmediatamente. Después de una purga masiva, seguimos recibiendo alertas de página hasta que VACUUM FULL se ejecutó fuera de línea. La capacidad debe tener en cuenta el tiempo de inactividad de limpieza y el espacio temporal que necesita.
Casos límite avanzados: compresión, particionado y peculiaridades de la nube
La compresión cambia las matemáticas de forma asimétrica
El columnstore de SQL Server o la compresión ZFS de PostgreSQL pueden reducir los datos 4×–10×. Pero los índices a menudo permanecen sin comprimir. Ten en cuenta esa asimetría: una tabla de 100 GB puede convertirse en 15 GB, pero su índice de 50 GB sigue en 45 GB. Aprendí esto cuando una afirmación de «ahorro de 10×» de un proveedor no se materializó a nivel de volumen.
El particionado convierte el crecimiento en un tope
Las particiones diarias te permiten eliminar datos antiguos al instante, convirtiendo la retención de un multiplicador de crecimiento en un tope fijo. Migré una tabla de auditoría de 2 TB a particiones mensuales y reduje la previsión en un 70% porque las particiones antiguas se archivaron en almacenamiento de objetos.
Consideraciones multiinquilino
En un esquema compartido, un inquilino ruidoso puede disparar las previsiones de crecimiento. Segmento las métricas por inquilino para detectar valores atípicos; un inquilino fue responsable del 60% de la expansión inesperada en una instancia de 800 GB.
Límites ocultos de los servicios gestionados
Amazon RDS PostgreSQL tiene un tamaño máximo de base de datos por clase de instancia, no solo un límite de volumen. Siempre verifica los límites oficiales de RDS antes de comprometerte. Aurora Serverless v2 escala la computación pero el almacenamiento sigue creciendo hasta que eliminas. Ningún servicio gestionado te exime de las matemáticas.
Compensación: sobredimensionar malgasta dinero; subdimensionar arriesga páginas a las 3 a.m. Recomiendo revisar la capacidad trimestralmente con métricas reales, no con suposiciones anuales. La incertidumbre es inherente: mantén siempre un margen del 20% para lo desconocido.
Poniendo la plantilla de la calculadora a trabajar
En un compromiso, detectamos un pico de crecimiento del 40% mes a mes en una base de datos de telemetría antes de que cruzara el 80% del disco, ahorrando una caída de fin de semana. La clave fue la repetibilidad: cada sprint, reejecuta los pasos 1–4. El cálculo de capacidad no es una tarea única; es un bucle de retroalimentación.
Combina medición, previsión y límites operativos y te adelantarás. Usa los fragmentos SQL, la tabla de multiplicadores y la lista de verificación como documentos vivos. Y si quieres el equivalente en hoja de cálculo, la Calculadora de capacidad de base de datos está lista.