Cada vez que toca renovar licencias de SQL Server hay una pregunta recurrente de todos mis clientes: ¿Y si migramos a PostgreSQL y nos ahorramos este dinero? Normalmente, quien me hace esta pregunta espera de mí un tajante NO. Sin embargo, hasta ahora mi respuesta siempre había sido: “Es una opción, claro. PostgreSQL es un excelente gestor de bases de datos y, si estás desarrollando una nueva aplicación y no tienes esa camisa de fuerza que es migrar todo tu código, me parece perfecto. Eso sí, asegúrate de tener un buen soporte.” Ahora bien, a día de hoy, BABELFISH for PostgreSQL ha mejorado lo suficiente como para hacerme cambiar esta respuesta. 

¿Qué es BABELFISH?

Empecemos por el principio, Babelfish es un complemento para PostgreSQL y ahora también para Aurora PostgreSQL (Amazon) que nos permite utilizar nuestra misma cadena de conexión SQL Server y nuestro código T-SQL sobre una base de datos de Postgre. Además de este “traductor” incorpora una funcionalidad de migración de nuestros datos desde cualquier versión licenciada de SQL hacía PostgreSQL.

¿Cómo funciona BABELFISH?

Paso 1. Instalación:

Como es lógico para empezar a trabajar con Babelfish lo primero que debemos hacer es instalarlo, para lo que necesitaremos un sistema operativo linux. Es importante destacar que la instalación de babelfish incluye la instalación de una versión de PostgreSQL con los componentes necesarios para su funcionamiento y no funcionará con una instalación de PostgreSQL desde cualquier otra fuente. Por suerte, el bundle de instalación de Babelfish incluye un fichero con las instrucciones detalladas paso a paso para completar la instalación de manera exitosa, eso sí, las instrucciones de instalación son para Ubuntu y los pasos pueden diferir ligeramente en otras distribuciones.

En caso de que queramos una versión cloud, Babelfish es una capacidad integrada de Amazon Aurora y no tiene coste adicional. Se puede habilitar Babelfish en Amazon Aurora desde la consola de administración de RDS.

Paso 2. Configuración:

Una vez concluida la instalación, es el momento de conectar a PostgreSQL y empezar a configurar todo. Para empezar crearemos un usuario que será propietario de la base de datos de muestra. Crearemos también la base de datos de muestra y definiremos si Babelfish va a trabajar en modo base de datos única o va a admitir varias bases de datos. Esta configuración no se va a poder cambiar por lo que si elegimos la opción single-db debemos estar muy seguros.

Paso 3. Migración:

Ahora que ya tenemos todo instalado y configurado toca entrar en materia y migrar los datos de nuestro SQL Server. Para la migración tenemos dos opciones otra vez, modo base de datos única o modo de múltiples bases de datos. Cada uno de los modos de migración tiene sus pros y sus contras y una vez más, una vez elegido uno no lo podremos cambiar. La primera vez que iniciemos Babelfish se crearán una base de datos master y una tempdb, si teníamos objetos creados en la master deberemos recrearlos en esta. En cuanto a la tempdb una vez creada no se borrará nunca al contrario de lo que pasa en SQL Server.

En el modo de migración de base de datos única, los nombres de los esquemas se crean tal cual, por lo que si el objetivo es terminar migrando a PostgreSQL nativo tendremos que terminar haciendo cambios en el código. Si este es nuestro objetivo (que, a estas alturas, debería serlo) es recomendable mover todas las tablas al esquema DBO en SQL Server antes de la migración.

Tendrás que elegir el modo de migración de múltiples bases de datos si quieres migrar varias bases de datos, si no tienes claras tus necesidades futuras o si lo que quieres es migrar varias bases de datos de usuarios juntas y el objetivo final no es realizar una migración PostgreSQL.

Siguientes pasos y conclusiones

En este punto ya estamos preparados para empezar a trabajar con Babelfish for PostgreSQL de manera transparente como si de un SQL Server se tratara, esto nos permitirá ir migrando gradualmente nuestras aplicaciones hasta conseguir un funcionamiento con PostgreSQL Nativo y podremos reinvertir el dinero ahorrado en licencias de SQL Server en un mejor hardware y/o en un soporte de alto nivel para PostgreSQL.