MySQL y PostgreSQL como opciones backend nativas

Elegir la base de datos forma parte de la arquitectura del despliegue

En un sistema empresarial, la base de datos no depende únicamente de la preferencia de quien desarrolla. La empresa puede tener estándares operativos, un equipo propio de administración, procedimientos de copia de seguridad existentes, requisitos del proveedor cloud o limitaciones de un alojamiento gestionado. Por eso Sapphire I.C.D.S. admite dos opciones backend nativas, MySQL y PostgreSQL, sin obligar a todas las instalaciones a utilizar un único sistema elegido de antemano.

El Roadmap público registra el soporte de PostgreSQL como una mejora publicada junto con la selección completa entre ambos sistemas. Desde el punto de vista arquitectónico, esto significa más que disponer de un segundo controlador: las consultas, los esquemas de los módulos y las reglas de ejecución deben existir para ambos dialectos y conservar un comportamiento comparable.

Un contrato común sobre dos controladores

Las capas superiores de Sapphire I.C.D.S. no deben depender directamente de la biblioteca cliente de una base de datos concreta. El controlador de datos lee el tipo de backend elegido en la configuración y obtiene el controlador nativo correspondiente. Para el módulo que realiza la llamada permanece un conjunto común de operaciones: seleccionar filas, modificar datos, obtener un valor escalar, insertar lotes, gestionar transacciones y operar con el esquema.

Esta separación mantiene la elección tecnológica en la capa de infraestructura. Un módulo de artículos o localización formula una solicitud de dominio y trabaja con un resultado estructurado, sin decidir cómo conectarse a MySQL o PostgreSQL. Las diferencias entre ambos sistemas tampoco se ocultan mediante una abstracción ficticia: las tratan el controlador y el dialecto SQL correspondientes.

Plantillas SQL separadas en lugar de cadenas condicionales

Sapphire I.C.D.S. mantiene las consultas ordinarias separadas del módulo de negocio y las divide por dialecto. Una misma operación puede disponer de plantillas para MySQL y PostgreSQL con la misma finalidad y la misma forma esperada del resultado. Antes de la ejecución, el controlador activo selecciona la variante adecuada, aplica la capa de parámetros nativa y devuelve los datos en un contenedor tabular común.

Es una portabilidad más honesta que declarar universal todo el SQL. MySQL y PostgreSQL difieren en sintaxis, tipos, tratamiento de identificadores, devolución de valores creados y detalles de determinadas expresiones. Las plantillas separadas y verificables permiten manejar esas diferencias de forma explícita sin llenar el módulo de negocio de bifurcaciones.

Qué permanece igual para los módulos

• La operación de dominio. Solicitar una lista, guardar un registro o realizar un cambio transaccional mantiene una finalidad de negocio única.
• Los datos de entrada. El módulo transmite parámetros estructurados mediante el entorno común.
• La forma del resultado. El consumidor recibe una tabla o un valor con campos acordados.
• El límite transaccional. Las operaciones que deben completarse íntegramente usan el contrato común de transacciones.
• La selección del backend. La realizan la configuración y el controlador, no condiciones dispersas por los módulos.

Qué no hace automáticamente la selección del backend

La existencia de dos opciones nativas no significa que una base de producción activa pueda cambiarse con un único ajuste. Migrar entre sistemas exige trasladar esquemas y datos, comprobar secuencias e identificadores, comparar tipos y controlar codificaciones, índices y comportamiento transaccional. Se necesitan una copia de seguridad, un plan de interrupción o sincronización, una ejecución de prueba y criterios de reversión.

La plataforma tampoco afirma ofrecer replicación automática entre MySQL y PostgreSQL, failover integrado entre sistemas ni un clúster único compuesto por bases diferentes. Son tareas de infraestructura que deben diseñarse por separado. La selección nativa significa que Sapphire I.C.D.S. funciona con cada opción en un despliegue compatible, no que ambas puedan intercambiarse en cualquier momento sin preparación.

Cómo elegir entre MySQL y PostgreSQL

Una decisión racional comienza por el entorno del cliente. Si la organización ya utiliza MySQL, dispone de copias de seguridad estandarizadas y cuenta con un equipo competente, cambiar de sistema solo por un proyecto nuevo puede no aportar ventajas. Del mismo modo, PostgreSQL es natural donde constituye el estándar empresarial, está disponible como infraestructura gestionada y encaja con la supervisión y la recuperación existentes.

No debe compararse solo el rendimiento de una consulta, sino todo el ciclo de vida: disponibilidad de especialistas, actualizaciones, coste del servicio, observabilidad, política de extensiones, recuperación y requisitos de datos. Las consultas particulares de un módulo deben medirse con volúmenes representativos. Un contrato común no elimina las diferencias entre optimizadores e índices.

La paridad exige disciplina de desarrollo

Cada cambio de esquema o consulta debe existir en ambos dialectos cuando el módulo declara compatibilidad con los dos backend. No basta con comprobar la presencia de las plantillas: se requieren una instalación limpia, la reaplicación segura de migraciones, pruebas de lectura y escritura y comparación de resultados. Hay que prestar especial atención cuando cada sistema informa de manera distinta sobre filas modificadas o trata de otro modo un resultado vacío.

Esta disciplina amplía el esfuerzo de verificación, pero convierte la portabilidad en una realidad. Si un módulo nuevo solo funciona con un backend, debe registrarse como limitación en lugar de ocultarse tras una afirmación general. La dirección técnica obtiene un criterio claro: la misma operación de negocio debe producir un resultado equivalente en las dos opciones compatibles.

Resultado operativo

Para el propietario, dos backend nativos permiten adaptar Sapphire I.C.D.S. a la infraestructura existente y evitar cambios innecesarios de competencias. Para arquitectura, la capa común impide que los módulos se vinculen directamente a un controlador. Para desarrollo, los dialectos SQL separados hacen visibles y verificables las diferencias.

El valor principal no es proclamar compatibilidad con dos bases de datos, sino establecer una frontera de responsabilidades. La organización elige y opera el backend; el controlador conecta la opción nativa; el módulo ejecuta la operación de dominio; y las pruebas confirman la paridad. Así se mantiene abierta la elección tecnológica sin ocultar el coste real de migración y mantenimiento.