Cada cierto tiempo aparece la misma conversación en empresas que llevan años trabajando con SQL Server: “¿Y si migramos a PostgreSQL y nos ahorramos las licencias?”. La pregunta es legítima. Lo que no es legítimo es convertirla en una decisión de arquitectura basada únicamente en el coste de la licencia de SQL Server vs la de PostgreSQL gratis. PostgreSQL se distribuye bajo una licencia open source permisiva, similar a BSD o MIT, y eso elimina una parte importante del coste directo de producto. Pero eliminar una factura no elimina la complejidad técnica, ni la necesidad de soporte, ni la responsabilidad de que producción siga funcionando el lunes a las nueve.
Antes de hablar de migración conviene poner algo de orden, porque aquí se mezclan conceptos con una complejidad que no deberían tratarse sin supervisión adulta (y experta).
Licencias no es lo mismo que coste total
SQL Server tiene un modelo de licenciamiento que puede pesar mucho, especialmente en entornos con bastantes cores, virtualización, alta disponibilidad, entornos de contingencia y cargas críticas. Microsoft mantiene modelos por core, virtualización, Software Assurance, pago por uso y otros escenarios que hay que entender con lupa, café y, preferiblemente, alguien de licencias cerca. En Azure Arc, por ejemplo, Microsoft documenta opciones de licencia por vCore, core físico y virtualización ilimitada bajo determinadas condiciones. También contempla instancias pasivas para HA/DR en ciertos escenarios. No es precisamente “siguiente, siguiente, finalizar”.
PostgreSQL, por su parte, no te cobra por usar el motor comunitario. Pero alguien tiene que diseñar la arquitectura, mantenerla, parchearla, monitorizarla, hacer backups, probar restauraciones, resolver incidencias y explicar por qué una query que iba bien en SQL Server ahora ha decidido explorar su lado artístico. Ese alguien puede ser tu equipo interno, un proveedor especializado o un servicio gestionado. En todos los casos hay coste. Simplemente cambia de sitio. Y si, ya sé que me vais a decir que todo esto también lo necesitamos en SQL Server pero en este caso tenemos la opción de un soporte por debajo que no tenemos en PostgreSQL.
Esta es la primera trampa habitual, comparar la licencia de SQL Server contra cero. La comparación real debería ser SQL Server con su ecosistema, soporte, HA, herramientas y conocimiento interno frente a PostgreSQL con su ecosistema, soporte contratado o comunitario, nuevas herramientas, curva de aprendizaje y esfuerzo de migración.
Y sí, se puede ahorrar dinero. Mucho, incluso. Pero si el ahorro sale de dejar sin cubrir soporte, disponibilidad o mantenimiento, no es ahorro, es deuda técnica.
Cuando bajamos del Excel de compras a la producción real, la conversación empieza a ponerse interesante.
Soporte: nadie llama a “la comunidad” a las tres de la mañana
SQL Server tiene una política de ciclo de vida definida por Microsoft. Por ejemplo, SQL Server 2022, tiene soporte mainstream hasta enero de 2028 y soporte extendido hasta enero de 2033. SQL Server 2025 amplía ese horizonte, con soporte mainstream hasta enero de 2031 y extendido hasta enero de 2036.
PostgreSQL también tiene política de versiones, pero con otro enfoque. El PostgreSQL Global Development Group publica una versión mayor aproximadamente una vez al año y mantiene cada versión mayor durante cinco años. Después llega el final de vida y toca actualizar. En septiembre de 2026, PostgreSQL 18 es la rama estable actual y PostgreSQL 19 está en beta, no recomendado para producción.
Esto no es mejor ni peor por sí mismo. Es diferente. En SQL Server compras producto, soporte y un marco empresarial muy claro. En PostgreSQL tienes un motor excelente, una comunidad muy potente y un mercado amplio de proveedores, pero debes decidir quién te da soporte, con qué SLA, sobre qué distribución, en qué plataforma y con qué responsabilidad contractual.
Para una aplicación interna pequeña, quizá baste con conocimiento propio y una buena política de actualizaciones. Para una plataforma crítica, con penalizaciones por caída, auditoría y ventanas de mantenimiento ridículas, necesitas algo más serio que “lo miramos en Stack Overflow”. Que todos hemos pecado, pero tampoco hace falta convertirlo en estrategia corporativa.
Después viene la pregunta incómoda que muchos evitan hasta que ya es tarde: ¿cómo vamos a mantener la disponibilidad?
Alta disponibilidad: no basta con levantar una réplica y rezar
SQL Server tiene Always On Availability Groups como una solución integrada de alta disponibilidad y recuperación ante desastres. Permite agrupar bases de datos, conmutarlas juntas, usar réplicas síncronas o asíncronas, listener para redirigir conexiones y herramientas integradas de administración y monitorización. En Enterprise ofrece un conjunto bastante completo, en Standard existen Basic Availability Groups con limitaciones.
PostgreSQL también soporta alta disponibilidad mediante replicación, standby, streaming WAL, hot standby y otras piezas del ecosistema. La propia documentación habla de servidores que trabajan juntos para permitir que un secundario tome el control si falla el primario, o para repartir lecturas en ciertos escenarios.
La diferencia está en el empaquetado. En SQL Server muchas piezas vienen dentro de una solución reconocible, aunque luego haya que configurarla bien, que tampoco es magia negra pero se le parece. En PostgreSQL normalmente compones la arquitectura con varias herramientas: replicación nativa, Patroni o repmgr para failover, etcd o Consul para consenso, pgBackRest o Barman para backups, HAProxy o PgBouncer para conexiones, más monitorización específica.
¿Funciona? Sí. ¿Es robusto? Puede serlo muchísimo. ¿Es “instalo PostgreSQL y ya tengo Always On”? No. Y quien lo venda así probablemente te está engañando para venderte el servicio.
El punto no es que SQL Server gane siempre en HA ni que PostgreSQL sea artesanal. El punto es que la arquitectura objetivo debe diseñarse. Hay que definir RPO, RTO, failover automático o manual, fencing, split-brain, backups, restauraciones, pruebas de conmutación, impacto en conexiones y comportamiento de la aplicación. La base de datos no es solo el motor, es el servicio completo.
Hay otra lectura interesante si la conversación se produce en entornos cloud de Microsoft. PostgreSQL no obliga necesariamente a salir de Azure. A veces el debate se plantea como si la única alternativa a SQL Server fuese montar PostgreSQL a pelo en unas máquinas virtuales y encomendarse al santo patrón del `systemctl status`. No tiene por qué ser así.
PostgreSQL también vive en Azure, con sus propias reglas
Azure Database for PostgreSQL Flexible Server permite desplegar PostgreSQL como servicio gestionado, con opciones de alta disponibilidad en la misma zona o con redundancia entre zonas, creando una réplica standby físicamente separada del primario. Microsoft documenta también un SLA del 99,99% cuando se habilita la resiliencia zonal, con las limitaciones habituales que conviene leer antes de creer la disponibilidad que nos venden en una reunión comercial.
Esto cambia parte de la ecuación. Si ya estamos en Azure, puede tener sentido evaluar PostgreSQL gestionado en lugar de autogestionar el motor. Ganamos automatización, integración con Azure, backups gestionados, operación más cómoda y una vía más natural para equipos que ya trabajan con identidades, redes, monitorización y seguridad dentro de la plataforma de Microsoft. Pero no conviene confundir “servicio gestionado” con “servicio sin decisiones”. Sigue habiendo que diseñar conectividad, seguridad, parámetros, mantenimiento, réplicas, pruebas de recuperación, costes y observabilidad. Azure te quita trabajo operativo, no criterio técnico.
Y en esa misma línea aparece Azure HorizonDB, actualmente en preview. Microsoft lo presenta como un servicio de base de datos cloud-native, totalmente gestionado, preparado para cargas críticas y construido sobre PostgreSQL, con separación de cómputo y almacenamiento, diseño “database-as-log”, alta disponibilidad y capacidades orientadas a IA, incluyendo soporte para vectores e integración con Azure AI Foundry Tools.
¿Significa eso que HorizonDB debe entrar mañana en producción para sustituir cualquier SQL Server incómodo? No tan rápido. Que ponga PostgreSQL-compatible no significa que desaparezcan las pruebas de compatibilidad, rendimiento, comportamiento transaccional y operación. Además, al estar en preview, todavía arrastra limitaciones relevantes. Microsoft documenta, entre otras, la ausencia de réplicas de lectura entre regiones para recuperación ante desastres, retención de backup no configurable más allá del estado actual del servicio y disponibilidad regional limitada.
Y entonces llega la parte que suele romper presupuestos: el código.
T-SQL no se convierte en PL/pgSQL con incienso
Si la aplicación usa SQL Server como simple almacén relacional y apenas contiene lógica en base de datos, la migración puede ser razonable. Habrá que adaptar tipos de datos, sintaxis, funciones, paginación, fechas, identidades, esquemas, collations, bloqueos y alguna alegría más. Pero es abordable.
Si la aplicación tiene procedimientos almacenados, funciones escalares, funciones de tabla, triggers, jobs, SQL dinámico, cursores, transacciones complejas, `MERGE`, temporales, hints, `TRY…CATCH`, `OUTPUT`, `ROWVERSION`, `IDENTITY`, `SEQUENCE`, `XML`, `JSON`, `geography`, `hierarchyid` o dependencias con SQL Agent, entonces ya no estamos migrando una base de datos. Vamos a terminar reescribiendo una gran parte del sistema.
SQL Server define los procedimientos almacenados como grupos de instrucciones Transact-SQL o referencias a métodos CLR, con parámetros, salida y lógica procedural dentro del motor. PostgreSQL usa PL/pgSQL como lenguaje procedural para funciones, triggers y procedimientos, pero su modelo, sintaxis y comportamiento no son equivalentes uno a uno.
Un ejemplo muy típico: en SQL Server hay código que depende de tablas temporales, variables de tabla, `@@ROWCOUNT`, `SCOPE_IDENTITY()`, `GETDATE()`, `ISNULL()`, `TOP`, hints de bloqueo o comportamiento concreto de transacciones. En PostgreSQL encontrarás alternativas, pero no siempre sustitutos directos. A veces el cambio es trivial. A veces exige rediseñar.
Y luego está `MERGE`. SQL Server lo soporta desde hace años y PostgreSQL también lo tiene en versiones modernas, pero eso no significa que puedas copiar y pegar alegremente. La propia documentación de SQL Server advierte sobre cuestiones de rendimiento, concurrencia y pruebas exhaustivas en `MERGE`.
Cuanta más lógica viva dentro de SQL Server, más se parece la migración a un proyecto de desarrollo. No de infraestructura. De desarrollo.
Hay otro escenario que se usa mucho como comodín para tranquilizar conciencias: “no pasa nada, usamos ORM”.
ORM: el anestésico que no siempre duerme lo suficiente
Cuando todo el acceso a datos pasa por un ORM, la migración puede ser más sencilla, pero no automática. Un ORM ayuda a abstraer parte del código SQL, pero no elimina la semántica del motor. Las migraciones generadas, los tipos, las claves, los índices, las consultas LINQ o HQL complejas, el SQL nativo incrustado, los filtros globales, la paginación, los bloqueos optimistas y las estrategias de carga pueden comportarse de forma distinta.
Además, muchos proyectos dicen “todo va por ORM” hasta que alguien encuentra una carpeta llamada `LegacySql`, `RawQueries`, `Reports`, `CustomRepository`, `NoTocar`, o mi favorita: `Temporal`. Ahí dentro suele vivir media aplicación, un informe que factura millones y una query escrita por alguien que ya no trabaja en la empresa pero cuyo espíritu sigue bloqueando tablas.
Si el ORM genera SQL estándar y el modelo es limpio, perfecto. Pero hay que probar rendimiento real. SQL Server y PostgreSQL tienen optimizadores distintos, estadísticas distintas, planes distintos y patrones de indexación que no siempre coinciden. Un índice que tiene sentido en SQL Server no tiene por qué resolver igual en PostgreSQL, y viceversa.
También cambian los mecanismos de concurrencia. SQL Server puede trabajar con distintos niveles de aislamiento, row versioning mediante RCSI o snapshot, bloqueos con hints y un comportamiento que muchos equipos ya conocen. PostgreSQL usa MVCC de forma natural, con autovacuum como pieza crítica del mantenimiento. Ignorar autovacuum en PostgreSQL es como ignorar tempdb en SQL Server, puedes hacerlo, pero luego no pongas cara de sorpresa.
Por eso, incluso con ORM, una migración seria necesita pruebas funcionales, pruebas de carga, revisión de SQL generado, revisión de índices y validación de planes. El conector es solo una parte. Cambiarlo y celebrar es una magnífica forma de crear una incidencia.
La pregunta final es quizá la más importante: ¿hablamos de una aplicación existente o de un proyecto nuevo?
Migrar legacy no es lo mismo que empezar de cero
Para un proyecto nuevo, PostgreSQL puede ser una decisión magnífica. Permite diseñar desde el principio pensando en su modelo, sus tipos, su ecosistema, su estrategia de HA, su observabilidad y sus herramientas. El equipo desarrolla con PostgreSQL, prueba con PostgreSQL y despliega con PostgreSQL. No hay traducción cultural ni arqueología de procedimientos almacenados.
En una aplicación existente sobre SQL Server, la decisión cambia. Hay que inventariar objetos, dependencias, código T-SQL, jobs, integraciones, informes, ETLs, permisos, usuarios, linked servers, paquetes SSIS, mantenimiento, backups, auditoría, cifrado y automatización. También hay que medir cuánto conocimiento real tiene el equipo sobre SQL Server y cuánto tendrá sobre PostgreSQL después de la migración.
No es raro que el coste de licencia sea visible y el coste de reescritura esté escondido. La licencia aparece en una factura. El coste de migración aparece en retrasos, bugs, regresiones de rendimiento, noches raras y reuniones donde alguien dice “en preproducción iba bien”. Maravilloso epitafio técnico.
Una migración puede tener sentido cuando el ahorro recurrente compensa el esfuerzo inicial, cuando se quiere reducir dependencia de proveedor, cuando el equipo domina PostgreSQL o quiere invertir en ello, cuando la aplicación tiene una capa de datos razonablemente limpia, o cuando el producto necesita desplegarse en muchos clientes sin arrastrar licencias. Pero no debería justificarse solo con “PostgreSQL es gratis”.
También hay escenarios híbridos. Algunas aplicaciones nuevas pueden nacer en PostgreSQL mientras sistemas críticos existentes siguen en SQL Server. O se puede migrar por dominios, empezando por módulos menos acoplados. No todo tiene que resolverse con una migración big bang.
El criterio técnico debería ser bastante simple, aunque no siempre cómodo.
Conclusión: cambia de motor si tiene sentido, no porque la factura moleste
PostgreSQL es un motor excelente. SQL Server también. La comparación seria no va de religión tecnológica ni de camisetas de comunidad contra licencias corporativas. Va de coste total, soporte, disponibilidad, conocimiento, compatibilidad, código existente, rendimiento y riesgo operativo.
Si hablamos de un desarrollo nuevo, PostgreSQL merece estar en la mesa desde el primer minuto. Si hablamos de migrar una aplicación existente con años de T-SQL, procedimientos almacenados, jobs, informes y dependencias, hay que hacer inventario, pruebas y números de verdad. No números de PowerPoint, números de producción.
Migrar para ahorrar licencias puede ser una gran decisión. Migrar creyendo que basta con cambiar el conector es una invitación formal al desastre. Y producción, como ya sabemos, siempre acepta invitaciones.
