¿Base de datos integrada o externa? Cómo elegir una arquitectura de base de datos para una aplicación autoalojada

Empiece por el límite operativo, no por la opción que parece más sofisticada

Para una aplicación basada en Docker, una base de datos integrada suele significar que la aplicación y su servicio de base de datos compatible se definen como parte de la misma aplicación de Compose. Pueden ejecutarse en contenedores separados, mientras que la base de datos conserva sus datos en un volumen de Docker. Una base de datos externa es un servicio de base de datos operado por separado al que la aplicación accede mediante una conexión configurada.

Ninguna de las dos disposiciones es intrínsecamente más fiable, segura o profesional. La pregunta útil es: ¿qué equipo es responsable de todo el límite del servicio y puede ese equipo operar correctamente sus dependencias, cambios y procedimientos de recuperación?

Una base de datos integrada puede ser el diseño de menor riesgo cuando la aplicación la admite oficialmente y un equipo pequeño necesita una pila contenida con un ciclo de vida claro. Una base de datos independiente puede ser adecuada cuando la documentación de la aplicación lo exige, cuando cargas de trabajo aprobadas realmente necesitan un servicio compartido o cuando un equipo de bases de datos o de infraestructura ya cuenta con procedimientos operativos definidos para ese servicio.

• Elija el límite operativo más pequeño que cumpla los requisitos documentados de la aplicación.
• No trate «externa» como sinónimo de resiliente ni «integrada» como sinónimo de desechable.
• Tome la decisión por aplicación y por modelo de despliegue documentado, en lugar de adoptar una única regla para todas las cargas de trabajo.

Verifique el modelo de despliegue compatible con la aplicación antes de diseñar la infraestructura

La documentación de la propia aplicación es la autoridad para determinar si admite una base de datos integrada, una base de datos externa o ambas. Realice esta tarea antes de aprovisionar un host o migrar datos de producción. Una cadena de conexión técnicamente posible no demuestra que un patrón de despliegue sea compatible durante actualizaciones, migraciones o recuperación de incidentes.

Compruebe los requisitos documentados del motor y de la versión de la base de datos. A continuación, compruebe exactamente cómo recibe la aplicación los ajustes de conexión, cómo realiza las migraciones de esquema, si espera una extensión o un paso de inicialización específico de la base de datos y si documenta supuestos de alta disponibilidad o de copias de seguridad.

El comportamiento de inicio también importa. En Compose, que una dependencia se haya iniciado no significa por sí solo que esté lista para aceptar conexiones a la base de datos. Docker documenta que Compose normalmente espera que un contenedor de dependencia esté en ejecución, no que esté listo. Cuando el despliegue de la aplicación lo requiera, una comprobación de estado de la base de datos y una condición de dependencia service_healthy pueden evitar que una aplicación intente su conexión inicial demasiado pronto.

• Motor de base de datos compatible, versión principal y cualquier extensión requerida.
• Ajustes de conexión compatibles y si TLS, certificados o reglas de red son requisitos documentados.
• Comando de migración, momento de la migración, comportamiento ante fallos y orientación para la reversión.
• Ruta de actualización compatible tanto para la aplicación como para la base de datos.
• Orientación sobre copias de seguridad, restauración y alta disponibilidad publicada por el proveedor de la aplicación.
• Expectativas sobre la secuenciación de inicio y las comprobaciones de estado.

Mapee la ruta completa de los datos: la base de datos relacional rara vez es todo el sistema

Antes de seleccionar una arquitectura de base de datos, identifique cada componente que conserve estado persistente o crítico para la seguridad. La base de datos relacional puede ser la fuente autorizada para los registros de la aplicación, pero la misma aplicación también puede depender de almacenamiento de archivos, almacenamiento de objetos, una caché, un índice de búsqueda, una cola, archivos de configuración y secretos. Cada uno puede tener un modelo distinto de persistencia, copia de seguridad y restauración.

Docker Compose distingue recursos como servicios, volúmenes, configuraciones y secretos. Esta distinción es operativamente importante. Un volumen con nombre de Docker puede sobrevivir a la eliminación de un contenedor, lo que separa el ciclo de vida de un contenedor de base de datos del ciclo de vida de los datos de la base de datos. Sin embargo, no establece que simplemente copiar un directorio de datos de una base de datos activa sea una copia de seguridad coherente de la base de datos.

Elabore un inventario que identifique la fuente autorizada de cada tipo de dato. Esta es la base de un plan de recuperación, un plan de migración y una respuesta precisa a la pregunta: «¿Qué perdemos si este componente no está disponible o se restaura desde un momento anterior?»

• Base de datos relacional: registros transaccionales de la aplicación, identidades, ajustes o metadatos, cuando esté documentado.
• Almacenamiento de archivos u objetos: cargas, adjuntos, exportaciones generadas, contenido multimedia o documentos, cuando se utilicen.
• Caché: determine si puede reconstruirse de forma segura o si contiene estado que afecta a la recuperación.
• Índice de búsqueda o almacén vectorial: determine si es autoritativo o si puede reconstruirse desde otra fuente.
• Estado de cola o de flujo de trabajo: identifique si el trabajo pendiente debe conservarse y cómo se recupera.
• Configuración y secretos de la aplicación: conserve la configuración necesaria para reconectar componentes y descifrar o acceder a datos protegidos.

Cuándo una base de datos integrada es una elección acertada

Una base de datos integrada suele ser apropiada cuando constituye un despliegue de aplicación oficialmente documentado, la carga de trabajo tiene un alcance acotado y el mismo equipo puede operar la aplicación y la base de datos como un solo servicio. Limita el número de sistemas independientes que deben configurarse, supervisarse, modificarse y recuperarse conjuntamente.

Esta elección no significa tratar la base de datos como un componente auxiliar sin importancia. Sigue necesitando almacenamiento persistente, credenciales, cobertura de copias de seguridad, supervisión del crecimiento del almacenamiento, una ruta de actualización documentada y pruebas de restauración. Su ventaja es un límite de propiedad más simple, no la ausencia de operaciones de base de datos.

Para un equipo técnico pequeño, esto puede ser más fácil de entender que un servicio remoto con rutas de red, reglas de firewall, gestión de cuentas y ventanas de cambio separadas. Mantenga claro el límite: la pila de la aplicación y su base de datos se despliegan, actualizan y recuperan como un sistema coordinado.

• El proveedor documenta el despliegue integrado como compatible.
• Un equipo es responsable tanto de la aplicación como del ciclo de vida de la base de datos.
• La política, la arquitectura o la orientación del proveedor no exigen un servicio de base de datos dedicado.
• El equipo puede realizar copias de seguridad y restaurar la base de datos y cada almacén autorizado relacionado.
• La pila tiene un modelo claro de almacenamiento persistente, en lugar de depender del sistema de archivos transitorio del contenedor.

Cuándo se justifica una base de datos externa

Utilice una base de datos operada por separado cuando exista un requisito concreto, en lugar de una preferencia por la separación. Entre las razones válidas se incluyen la arquitectura documentada de una aplicación, un equipo de bases de datos existente con procedimientos claros de propiedad y recuperación, o una necesidad real de que varias cargas de trabajo aprobadas utilicen un servicio de base de datos compartido.

Un servicio compartido no debería convertirse en un lugar donde volcar sin criterio aplicaciones no relacionadas. Cada carga de trabajo sigue necesitando roles de base de datos definidos, límites de acceso, coordinación del mantenimiento y una decisión de recuperación. Compartir un motor o un clúster no elimina la necesidad de aislar las credenciales y decidir quién puede realizar cambios.

Una plataforma especializada de bases de datos o un equipo interno de infraestructura puede ser la mejor opción cuando la organización ya cuenta con las habilidades, los controles y el modelo de servicio para operarla. Ese equipo debe poder indicar quién gestiona los accesos, las actualizaciones, la verificación de copias de seguridad, las restauraciones, la capacidad y la respuesta a incidentes. Si estas respuestas no están claras, trasladar la base de datos a otro lugar puede limitarse a trasladar trabajo sin responsable.

• El proveedor de la aplicación documenta una base de datos externa como obligatoria o compatible para el despliegue previsto.
• Un equipo designado es responsable de las operaciones de la base de datos y cuenta con un procedimiento de recuperación probado.
• La conectividad de red, la autenticación y la gestión del firewall tienen responsables claros.
• La necesidad de un servicio compartido es real, está aprobada y es compatible con un aislamiento de acceso adecuado.
• El mantenimiento de la aplicación y de la base de datos puede coordinarse, incluidas las migraciones de esquema y las actualizaciones de versión principal.

No confunda separación con resiliencia

Una base de datos externa introduce otro límite de servicio. La aplicación pasa a depender de la accesibilidad de red, la resolución de nombres de host, las reglas de firewall y enrutamiento, las credenciales, las reglas de autenticación, la configuración del listener de la base de datos y el calendario de mantenimiento del servicio externo. Cada una de estas dependencias necesita un responsable y una vía de respuesta ante incidentes.

En el caso específico de PostgreSQL, la exposición de conexiones TCP/IP se rige por ajustes como listen_addresses, mientras que la autenticación de clientes controla quién puede conectarse. PostgreSQL también utiliza roles para la gestión de privilegios, y el usuario activo de la base de datos determina el acceso a los objetos de esta. Son controles útiles, pero deben diseñarse y mantenerse deliberadamente.

La separación puede mejorar la arquitectura de una organización cuando se ajusta a capacidades ya establecidas. También puede añadir latencia, más coordinación de gestión de cambios y una superficie de fallo más amplia. Evalúe toda la ruta desde el proceso de la aplicación hasta la base de datos, no solo el host de la base de datos.

• ¿Puede la aplicación resolver y alcanzar el endpoint de la base de datos en las condiciones de fallo previstas?
• ¿Qué rutas de red y reglas de firewall permiten la conexión?
• ¿Qué rol de base de datos utiliza la aplicación y qué privilegios necesita realmente?
• ¿Cómo se entregan, rotan y revocan las credenciales?
• ¿Quién aprueba el mantenimiento que podría afectar a la conectividad de la aplicación o a la compatibilidad del esquema?
• ¿Qué ocurre cuando la base de datos es accesible pero no está lista, está sobrecargada o se encuentra en recuperación?

Diseñe la recuperación como un procedimiento de sistema completo

Una copia de seguridad solo es útil si puede restaurar el servicio a un punto de recuperación acordado. Planifique la recuperación a través de toda la ruta de datos: la base de datos, los archivos cargados o el almacenamiento de objetos, la configuración de la aplicación, los secretos o el material de cifrado y el orden correcto de restauración. Una restauración satisfactoria únicamente de la base de datos aún puede dejar una aplicación incapaz de localizar archivos, autenticarse en servicios o descifrar datos protegidos.

Para PostgreSQL, la planificación de copias de seguridad requiere una elección deliberada entre volcados lógicos, copias de seguridad a nivel de sistema de archivos y archivado continuo. PostgreSQL documenta estos enfoques como distintos, con diferentes fortalezas y debilidades. Un volcado lógico creado con pg_dump genera comandos que recrean el estado de la base de datos capturado cuando comenzó el volcado; no equivale a simplemente copiar un volumen de contenedor.

Los objetivos de recuperación deben orientar la elección técnica. Si el punto de recuperación requerido exige restaurar a un momento entre copias de seguridad programadas, se necesitan capacidades que van más allá de los volcados lógicos ordinarios. La recuperación a un momento dado de PostgreSQL se basa en una copia de seguridad base más el archivado continuo del registro de escritura anticipada; la salida de pg_dump y pg_dumpall no puede utilizarse para la reproducción del registro de escritura anticipada.

Pruebe las restauraciones en un entorno aislado. Registre el tiempo de restauración, el punto recuperado, las comprobaciones de validación realizadas, los pasos manuales pendientes y quién autorizó el resultado. Considere que la evidencia de una prueba de restauración es más valiosa que una suposición basada en que una tarea de copia de seguridad haya informado de éxito.

• Identifique la fuente autorizada y el método de copia de seguridad de cada componente persistente.
• Establezca objetivos de punto de recuperación y tiempo de recuperación que el equipo pueda explicar y probar.
• Documente el orden de restauración, incluidas las bases de datos, los archivos, la configuración y los secretos.
• Verifique las identidades, roles y permisos necesarios para restaurar la propiedad y los privilegios de la base de datos.
• Realice pruebas periódicas de restauración y conserve los resultados.
• Compruebe que la validación a nivel de aplicación se realiza correctamente después de la restauración, no solo que el servicio de base de datos se inicia.

Asigne responsabilidades antes del lanzamiento a producción

La arquitectura está incompleta hasta que se asignan las responsabilidades operativas. Esto se aplica por igual a las bases de datos integradas y externas. Una base de datos puede ser técnicamente accesible y, aun así, ser operativamente insegura porque nadie es responsable del acceso privilegiado, el crecimiento del almacenamiento, los fallos de migración o la verificación de restauraciones.

Haga explícitas las responsabilidades en un manual operativo ligero o en un registro de propiedad del servicio. El objetivo no es la burocracia. Es garantizar que una migración fallida, una credencial vencida, un volumen creciente o una solicitud de recuperación tengan una vía de respuesta conocida.

Las actualizaciones de la base de datos merecen especial atención. PostgreSQL documenta métodos explícitos de actualización para versiones principales, incluidos enfoques de volcado y restauración. Una copia de seguridad a nivel de sistema de archivos no sustituye al método documentado de actualización mediante volcado y restauración. Coordine las versiones de base de datos compatibles con la aplicación con el procedimiento de actualización de la base de datos antes de una ventana de mantenimiento.

• ¿Quién aplica las actualizaciones de la base de datos y de la aplicación?
• ¿Quién controla el acceso de administrador y los roles rutinarios de base de datos de la aplicación?
• ¿Quién rota las credenciales y actualiza de forma segura la configuración de la aplicación?
• ¿Quién supervisa la capacidad, los fallos de conexión y el crecimiento del almacenamiento?
• ¿Quién aprueba y ejecuta las migraciones de esquema?
• ¿Quién responde si una migración falla o requiere reversión?
• ¿Quién es responsable de las copias de seguridad, las pruebas de restauración y la autorización de recuperación?
• ¿Quién coordina las actualizaciones de versiones principales de la base de datos con la compatibilidad de la aplicación?