Bases de datos gestionadas: qué gestiona el proveedor y qué no
Contratar una base gestionada delega el respaldo, el parche y la conmutación por falla. No delega el esquema, los índices, las consultas ni el plan de crecimiento, que es justo donde se rompen casi todas.
Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.
Una base gestionada se crea con tres clics y desde afuera parece la misma base de siempre: el mismo motor, el mismo cliente, la misma consulta. La diferencia aparece el día que algo sale mal, y ahí conviene saber de antemano cuál de las dos partes tiene el problema.
Porque hay un reparto, y no es el que uno supone: el proveedor se hace cargo de la máquina, y el que contrata se sigue haciendo cargo de los datos.
El reparto exacto
- Tu equipo
Datos
Lo que cargan tus usuarios y su clasificación
- Compartida
Identidad y permisos
Quién entra, con qué rol y hasta dónde llega
- Tu equipo
Aplicación
Tu código y su configuración
- Proveedor
Runtime y dependencias
Intérprete, bibliotecas, servidor de aplicaciones
- Proveedor
Sistema operativo
Kernel, parches, usuarios del sistema
- Proveedor
Virtualización
Hipervisor, aislamiento entre inquilinos
- Proveedor
Hardware y red física
Servidores, discos, switches, cableado
- Proveedor
Instalaciones
Edificio, energía, refrigeración, acceso físico
5 de 8 capas las opera el proveedor · 1 compartida · 2 quedan de tu lado · 5 menos que con un servidor propio
| Responsabilidad | Del proveedor | De quien contrata |
|---|---|---|
| Sistema operativo y parches del motor | Sí, en ventanas de mantenimiento | Elegir la ventana y la versión |
| Respaldos automáticos | Los toma y los retiene | Definir la retención y probar restaurar |
| Conmutación por falla | Automática si hay réplica en espera | Haberla contratado y reconectar el cliente |
| Esquema, índices y consultas | No | Todo |
| Tamaño de la instancia y almacenamiento | Los ofrece | Elegirlos y anticipar el crecimiento |
| Seguridad de la red y credenciales | Los mecanismos | Que la base no sea pública y rotar contraseñas |
Alta disponibilidad, réplicas de lectura y la diferencia entre las dos
Se confunden seguido porque las dos “son otra copia de la base”, pero resuelven problemas distintos y no se reemplazan entre sí.
| Réplica en espera (alta disponibilidad) | Réplica de lectura | |
|---|---|---|
| Para qué | Sobrevivir a la caída de una zona | Repartir carga de lectura |
| Se puede consultar | No, en general | Sí |
| Replicación | Sincrónica o casi | Asincrónica, con retraso |
| Qué pasa si se cae la principal | Promoción automática, de segundos a minutos | Promoción manual, con posible pérdida de datos |
| Costo | Duplica el de la instancia | Una instancia más por réplica |
Antes de seguir, predecí
Respaldos: lo que se contrata y lo que hay que probar
Los respaldos automáticos vienen incluidos y eso genera una tranquilidad que no siempre está justificada. Vale la pena mirar tres números concretos.
Los tres números de un respaldo
- Retención: cuántos días atrás se puede volver. El valor por defecto suele ser corto —del orden de una semana—, y un borrado que se descubre un mes después queda afuera.
- Punto en el tiempo: si el motor guarda además el registro de transacciones, se puede restaurar a un minuto exacto y no sólo al respaldo de la noche. Es lo que convierte un “perdimos el día” en “perdimos cinco minutos”.
- Tiempo de restauración: restaurar crea una instancia nueva, no sobrescribe la actual. Para una base grande eso puede tardar horas, y ese es el tiempo real de recuperación, no el que figura en el diagrama.
Cómo elegir entre las opciones del catálogo
| Necesidad | AWS | Google Cloud | Azure |
|---|---|---|---|
| Relacional gestionada, motores estándar | RDS (PostgreSQL, MySQL, MariaDB, SQL Server, Oracle) | Cloud SQL | Azure Database for PostgreSQL / MySQL / SQL |
| Relacional propia del proveedor, compatible | Aurora | AlloyDB | SQL Hyperscale |
| Relacional distribuida globalmente | Aurora DSQL | Spanner | Cosmos DB para PostgreSQL |
| Clave-valor y documentos a escala | DynamoDB | Firestore y Bigtable | Cosmos DB |
| Cache en memoria | ElastiCache y MemoryDB | Memorystore | Azure Managed Redis |
| Analítica sobre grandes volúmenes | Redshift y Athena | BigQuery | Synapse y Fabric |
La regla que evita casi todos los arrepentimientos: empezar por el motor estándar. PostgreSQL o MySQL gestionados corren el mismo motor que se puede correr en cualquier lado, así que la puerta de salida queda abierta. Las variantes propias del proveedor ofrecen mejor rendimiento y conmutación más rápida, y a cambio atan más fuerte; las distribuidas globalmente resuelven un problema —escribir en varias regiones con consistencia— que la mayoría de los sistemas no tiene.
Más a fondo · nivel seniorCuándo la base gestionada deja de alcanzar
Hay tres señales que suelen aparecer juntas cuando el problema ya no es de tamaño de instancia:
- El límite es de escritura, no de lectura. Las réplicas no ayudan y la única salida vertical es una instancia más grande, que tiene techo. Ahí aparecen el particionado por clave o un motor distribuido.
- Hace falta una extensión o una versión que el servicio no ofrece. Es el argumento más común para volver a administrar la base uno mismo, y conviene medirlo contra el costo de operarla.
- El costo del almacenamiento y las operaciones de entrada/salida supera al del cómputo. Suele indicar que hay datos históricos que no deberían estar en la base transaccional sino en el almacenamiento analítico.
Ninguna de las tres se arregla cambiando de proveedor: son decisiones de modelo de datos que el servicio gestionado no toma por nadie.
Cierre
Autoevaluación
¿Lo entendiste?
Práctica