Migrar de SQL Server a PostgreSQL: más que cambiar sintaxis
Hay un momento en casi todo proyecto de modernización de bases de datos donde alguien dice: "vamos a migrar de SQL Server a PostgreSQL". Y luego viene el silencio incómodo, porque todos saben lo que eso implica: cientos o miles de procedimientos almacenados escritos en T-SQL que hay que convertir, probar y validar.
La mayoría de los equipos asume que el camino es una conversión línea por línea. Copiar la lógica, ajustar la sintaxis, rezar para que funcione. Y técnicamente funciona. Pero hay una diferencia enorme entre código que funciona y código que funciona bien. En junio de 2026, Google Cloud presentó una demostración de su Database Migration Service (DMS) que ilustra exactamente esa diferencia — y vale la pena entenderla si estás evaluando este tipo de proyecto.
En este artículo exploramos qué hace diferente al enfoque de DMS, por qué importa técnicamente, y cómo aplica esto a empresas peruanas y latinoamericanas que están modernizando su infraestructura de datos.
El problema con la conversión literal de T-SQL
T-SQL, el dialecto de SQL que usa Microsoft SQL Server, tiene patrones muy arraigados que funcionan bien dentro de su propio ecosistema. Uno de los más comunes es el uso de tablas temporales para procesos de múltiples pasos: creas una tabla temporal, insertas datos, la actualizas con información adicional, y finalmente seleccionas el resultado.
Es un patrón procedural clásico. Intuitivo para quien lo escribió, pero con un costo real: cada paso escribe y lee datos físicamente en disco o en memoria temporal. Cuando ese mismo patrón se traduce literalmente a PL/pgSQL, el código resultante es funcional pero arrastra las mismas ineficiencias — o incluso las amplifica, porque PostgreSQL no está optimizado para ese estilo de trabajo.
Una herramienta básica de conversión copia esa lógica tal cual. El resultado: código que pasa las pruebas pero que deja sobre la mesa una parte importante del rendimiento que PostgreSQL puede ofrecer. Para una empresa con volúmenes de transacciones altos, esa diferencia se traduce directamente en costos de infraestructura y tiempos de respuesta.
Refactorización inteligente: de tablas temporales a CTEs
Lo que demuestra el Database Migration Service de Google Cloud es un enfoque distinto. En lugar de traducir el código T-SQL línea por línea, DMS entiende la intención del procedimiento y lo reimplementa usando los patrones nativos de PostgreSQL.
En el ejemplo presentado, un procedimiento llamado get_high_value_customers que usaba tablas temporales fue convertido automáticamente en una función PostgreSQL que usa una Common Table Expression (CTE). El resultado no es solo más corto y más limpio — es fundamentalmente más eficiente.
¿Por qué es mejor una CTE en este caso? Gemini, integrado en el flujo de DMS, lo explica con precisión: una CTE permite al query planner de PostgreSQL ver toda la operación como una sola unidad lógica. Esto le da al motor de base de datos la información que necesita para construir un plan de ejecución óptimo, eliminando las lecturas y escrituras intermedias en disco que requería la tabla temporal. Menos I/O, mejor plan de ejecución, menor latencia.
Lo que hace esto particularmente valioso no es solo el resultado — es que DMS también explica cada decisión. El equipo de desarrollo no solo recibe código migrado, recibe una lección de optimización de bases de datos en el proceso. Eso acelera la curva de aprendizaje del equipo y reduce la deuda técnica desde el primer día.
¿Cómo aplica esto en empresas de Perú y LATAM?
En la región, una parte importante de las empresas medianas y grandes tienen sus sistemas de gestión construidos sobre SQL Server. Muchas de ellas están evaluando migrar a PostgreSQL — ya sea por costos de licenciamiento, por querer correr en la nube, o porque están modernizando su arquitectura hacia microservicios y necesitan una base de datos más flexible y open source.
El desafío más grande que enfrentan no es técnico en abstracto — es el volumen de lógica de negocio encapsulada en procedimientos almacenados. Años de reglas de negocio, cálculos y procesos batch escritos en T-SQL que nadie quiere tocar porque "si funciona, no lo rompas".
Un enfoque de migración inteligente como el que propone DMS cambia el cálculo de riesgo. En lugar de enfrentar una reescritura manual costosa y propensa a errores, o una conversión literal que mantiene las ineficiencias, existe un camino intermedio: migrar y modernizar al mismo tiempo. El código migrado no solo funciona en PostgreSQL — funciona mejor que el original.
Para empresas que operan con Odoo sobre PostgreSQL, o que están construyendo nuevas capas de datos sobre bases open source, este tipo de herramienta reduce significativamente el tiempo de transición y el riesgo operativo.
¿Cómo aplica esto en tu empresa?
Si tu empresa está considerando una migración de SQL Server a PostgreSQL, hay algunas preguntas concretas que vale la pena responder antes de empezar:
- ¿Cuántos procedimientos almacenados tienen? Un inventario realista del volumen de código T-SQL es el primer paso para estimar el esfuerzo.
- ¿Qué patrones usan más? Tablas temporales, cursores y lógica procedural compleja son los candidatos que más se benefician de una refactorización inteligente.
- ¿Tu equipo conoce los patrones nativos de PostgreSQL? CTEs, window functions y funciones nativas de Postgres tienen una curva de aprendizaje. Una herramienta que explica las decisiones acelera esa adopción.
- ¿Están migrando solo la base de datos o también la aplicación? Si el ORM o la capa de acceso a datos también cambia, la estrategia de migración necesita coordinarse con el equipo de desarrollo.
La respuesta a estas preguntas define si una migración es un proyecto de semanas o de meses — y si el resultado final es código que simplemente funciona, o código que realmente mejora el rendimiento del sistema.
Conclusión
La migración de T-SQL a PL/pgSQL no tiene que ser un proceso doloroso de traducción manual. Las herramientas modernas como Google Cloud DMS demuestran que es posible migrar con confianza y, al mismo tiempo, modernizar la calidad del código. La clave está en entender que no se trata solo de cambiar sintaxis — se trata de adoptar los patrones que hacen a PostgreSQL genuinamente más eficiente.
En Consultoría-Ti trabajamos con empresas peruanas y latinoamericanas en proyectos de modernización de infraestructura de datos, incluyendo migraciones de bases de datos y optimización de arquitecturas sobre PostgreSQL. Si estás evaluando este tipo de proyecto y quieres entender el alcance real antes de comprometerte, conversemos.
👉 Contáctanos en Consultoría-Ti y evaluamos juntos tu caso.
Fuentes y Referencias
Google Cloud Tech — Converting T-SQL code to PL/pgSQL with confidence (YouTube)
✨ Contenido generado con ContentFlow — Consultoría-Ti