Por qué las empresas abandonan Oracle por PostgreSQL (y cómo hacerlo de forma segura)

En resumen El licenciamiento de Oracle se ha convertido en una carga financiera seria.
Un servidor de doble zócalo que ejecuta Oracle Enterprise Edition puede costar más de 350.000 € solo en licencias base, con 22% de tarifas anuales de soporte que aumentan cada año.
PostgreSQL es ahora la base de datos más utilizada entre los desarrolladores, con una adopción general del 55,6% y del 58,2% entre los desarrolladores profesionales en la encuesta Stack Overflow Developer Survey de 2025 y una madurez empresarial probada.
Companies that have made the switch report 70–80% reductions in database licensing costs.
Esta publicación explica qué está impulsando el éxodo y qué se necesita para migrar de forma segura.


Tu renovación de soporte de Oracle llega a tu escritorio.

El número es mayor que el año pasado.

Otra vez.

Te resistes.

Oracle dice que ese es el precio.

Firmas, porque no tienes otra opción ahora mismo.

Este escenario se repite en miles de departamentos de TI cada año.

Es la razón principal por la que las empresas ahora están evaluando seriamente la migración de Oracle a PostgreSQL en cifras que habrían sido impensables hace cinco años.

Después de 20 años gestionando entornos Oracle en empresas, incluyendo un importante banco europeo que opera una plataforma Exadata con 14.000 bases de datos y un banco español líder que opera Oracle RAC 12c y 19c de misión crítica, he sido testigo de este cambio de primera mano.

La pregunta que mis clientes me hacen ya no es “¿deberíamos migrar?”.

¿Cuándo y cómo lo hacemos sin romper nada?“

Esto es lo que necesitas saber.


¿Por qué Oracle es de repente tan caro?

Oracle Enterprise Edition cuesta alrededor de €43.000 por licencia de procesador, más un 22 % de% de tarifas de soporte anuales que se acumulan cada año.

Complementos como RAC, Particionamiento y Diagnostics Pack elevan las implementaciones completamente configuradas a dos o tres veces el costo base.

Oracle controla los precios a través de contratos negociados mediante acuerdos de confidencialidad; los clientes no tienen poder de negociación sobre el número final.

Un servidor Intel básico de doble zócalo con 16 núcleos cuesta 350.000 € solo en licencias básicas de EE, antes de cualquier opción adicional.

La mayoría de las empresas que ejecutan entornos de producción Oracle pagan por varios complementos sin darse cuenta.

En Lista de precios de tecnología de Oracle es público, pero las cantidades que las empresas pagan realmente se negocian bajo acuerdos de confidencialidad.

Oracle controla toda la conversación de precios.

Está diseñado así.


¿Está PostgreSQL realmente listo para cargas de trabajo empresariales?

Sí, y lo ha sido durante varios años.

PostgreSQL soporta transacciones ACID, particionamiento, replicación lógica, búsqueda de texto completo, JSON y consultas paralelas.

Según el Encuesta para desarrolladores de Stack Overflow 2025, tiene un% de adopción general de desarrolladores del 55,6 y un% entre desarrolladores profesionales del 58,2 — la base de datos más utilizada por los desarrolladores durante cuatro años consecutivos.

En Anuncio de lanzamiento de PostgreSQL 17 afirma que las cargas de trabajo de alta concurrencia pueden experimentar una mejora de hasta 2 veces en el rendimiento de escritura gracias a las mejoras en el procesamiento de WAL.

Treinta años de desarrollo continuo desde el proyecto POSTGRES en la UC Berkeley.

Un ecosistema comercial que ahora incluye EDB, Percona, Crunchy Data y Supabase, todos ellos ofreciendo soporte empresarial, herramientas de alta disponibilidad y servicios gestionados en la nube.

La brecha técnica con Oracle es real pero manejable.

No es la tecnología lo que hace fracasar las migraciones.

Lo que une a los equipos es subestimar la complejidad de la conversión de PL/SQL y las dependencias a nivel de aplicación.


¿Qué empresas están ahorrando realmente?

El caso financiero ya no es teórico.

Números reales de estudios de caso publicados:

La cifra de 70–80% de reducción de costos de licencias surge consistentemente en los estudios de caso.

El argumento es simple: PostgreSQL es gratuito.

Todavía pagas por la infraestructura, los contratos de soporte (si los deseas) y la migración en sí.

Pero el aumento anual compuesto de Oracle del 8-10 %% se detiene.

Permanentemente.


¿Cuáles son los riesgos ocultos de una auditoría de Oracle?

Las auditorías de Oracle se realizan en ciclos de 2 a 3 años y habitualmente encuentran opciones sin licencia —Diagnostics Pack, Tuning Pack, Partitioning— habilitadas sin que nadie se dé cuenta de las implicaciones de licenciamiento.

Cada uno genera tarifas retroactivas.

Las empresas que ejecutan Oracle en VMware se enfrentan a una exposición adicional: Oracle requiere licencias para cada host físico en un clúster de VMware, independientemente del uso real.

Las facturas de auditoría suelen ascender a seis o siete cifras.

Según Cumplimiento de reparación, la frecuencia de auditoría de Oracle ha ido aumentando desde 2024.

Los resultados rara vez son menores.

La exposición de VMware está particularmente subestimada: una pequeña implementación de Oracle en una gran granja de VMware puede generar una exposición de licencias de millones de euros.

Permanecer en Oracle conlleva su propio riesgo financiero.

Cuanto más tiempo permanezcas, más probable es que te enfrentes a una factura de auditoría que eclipse el costo de la migración.


Si no está seguro de si su entorno de Oracle es un buen candidato para la migración, ofrezco una evaluación de tarifa fija que responde exactamente a esa pregunta: registro de riesgos, puntuación de complejidad y una proyección realista de costo/beneficio. Ver el servicio de evaluación →


¿Es la migración técnicamente difícil?

La migración de Oracle a PostgreSQL es técnicamente compleja, pero manejable.

El movimiento de datos no es la parte difícil.

Las partes difíciles son la conversión de PL/SQL a PL/pgSQL, el mapeo de tipos de datos y las dependencias de la capa de aplicación.

Herramientas como ora2pg automatizan el 60-80% de la conversión de esquemas; el 20-40% restante requiere revisión manual y reescritura.

Oracle utiliza tipos de datos (NUMBER, VARCHAR2, DATE, CLOB) que no se corresponden directamente con los equivalentes de PostgreSQL.

Los paquetes, cursores y manejo de excepciones de PL/SQL deben reescribirse, no solo convertirse.

Los procedimientos almacenados que dependen de un comportamiento específico de Oracle (coerción implícita de tipos, la tabla DUAL, ROWNUM) necesitan un manejo cuidadoso.

ora2pg maneja la mayor parte de la conversión del esquema automáticamente.

No maneja los casos límite.

La conversión de código es donde necesitas a alguien que conozca ambas partes profundamente.


Cómo se ve realmente una migración segura

Una migración segura de Oracle a PostgreSQL sigue cinco fases:

Fase 1: Evaluación

Inventaría tus esquemas, procedimientos almacenados, objetos personalizados y dependencias de aplicaciones.

Aquí es donde encuentras las sorpresas.

Una evaluación de pago —típicamente de 3 días— te proporciona una cotización de proyecto de precio fijo y un registro de riesgos realista antes de que te comprometas a nada.

Fase 2: Conversión de Esquema y Código

Mapeo de tipos de datos, conversión de PL/SQL a PL/pgSQL, secuencias, particionamiento, disparadores y vistas.

Herramientas como ora2pg automatizan entre el 60 y el 80% de esto.

Los 20–40% restantes requieren una reescritura práctica.

Fase 3: Migración de datos

Carga inicial completa seguida de replicación continua mediante CDC (Captura de Datos Modificados) para mantener PostgreSQL sincronizado mientras Oracle permanece activo.

AWS DMS maneja esto bien para la mayoría de los entornos.

Fase 4: Pruebas

Validación funcional fila por fila.

Comparación de rendimiento frente a las bases de Oracle.

Pruebas de regresión de aplicaciones.

Esta fase dura más de lo que la mayoría de los equipos esperan.

Fase 5: Transición

Una ventana de mantenimiento planificada —tan corta como unos minutos con una estrategia de cero tiempo de inactividad— donde el tráfico cambia de Oracle a PostgreSQL.

Oracle se mantiene en funcionamiento pero congelado para una ventana de reversión, típicamente de dos a cuatro semanas.

Si surge un problema crítico en PostgreSQL, el tráfico puede ser devuelto a Oracle, aunque cualquier dato escrito en PostgreSQL durante ese período se perdería, por lo que la decisión de revertir debe tomarse rápidamente.

El cronograma varía desde 3 semanas para una base de datos pequeña con PL/SQL mínimo hasta 3 meses para un entorno de complejidad media.

Las grandes y altamente personalizadas bases de datos de Oracle requieren un ejercicio de alcance personalizado antes de comprometerse con un cronograma.


En resumen

Los costos de licencia de Oracle aumentan cada año.

Las auditorías están aumentando en frecuencia y severidad.

PostgreSQL ha alcanzado un nivel de madurez empresarial que lo convierte en un reemplazo creíble para la mayoría de las cargas de trabajo de Oracle.

Las empresas que han realizado la transición reportan reducciones del 70-80% en el gasto de licencias de bases de datos.

Tres cosas para llevarte de esta publicación:

  • El caso financiero para migrar de Oracle a PostgreSQL es sólido y se fortalece con cada aumento de precio de Oracle.
  • PostgreSQL está listo para producción. El riesgo está en cómo ejecutas la migración, no en la tecnología en sí.
  • La conversión de PL/SQL y las dependencias de las aplicaciones son las partes difíciles. El movimiento de datos no lo es.

Si está evaluando una migración de Oracle a PostgreSQL, el primer paso correcto es una evaluación del alcance.

Contáctame en rootfan.com para una llamada gratuita de 30 minutos para discutir su entorno.

No discurso de ventas — solo una conversación técnica sobre si la migración tiene sentido para su situación.


Preguntas frecuentes

¿Cuánto cuesta una migración de Oracle a PostgreSQL?

Depende del recuento de esquemas, la complejidad de PL/SQL y los requisitos de alta disponibilidad.
El primer paso es siempre una evaluación con tarifa fija que le proporciona un registro de riesgos y una cotización del proyecto antes de que usted se comprometa a nada.
Consulta el desglose completo de precios en la página de servicios en rootfan.com/services/.

¿Cuánto tiempo toma una migración de Oracle a PostgreSQL?

Una migración pequeña suele durar 3–4 semanas.
Una migración de complejidad media dura 2-3 meses.
El cronograma depende principalmente del volumen de código PL/SQL, el número de dependencias de la aplicación y el nivel de pruebas requerido antes de la puesta en producción.
Una evaluación adecuada te da una estimación precisa antes de comprometerte.

¿Puede PostgreSQL manejar la disponibilidad a nivel de Oracle RAC?

PostgreSQL logra alta disponibilidad a través de etcd para el estado del clúster y la elección de líder, Patroni para la conmutación por error automática, y HAProxy o una IP virtual para enrutar las conexiones al primario actual.
Esta arquitectura proporciona una alta disponibilidad sólida para la mayoría de las cargas de trabajo.
Para cargas de trabajo extremadamente intensivas en escrituras que dependen del modelo de disco compartido de Oracle RAC, la arquitectura de alta disponibilidad (HA) requiere una evaluación cuidadosa durante la fase de análisis.

¿Funcionarán mis paquetes PL/SQL en PostgreSQL?

No sin conversión. PostgreSQL utiliza PL/pgSQL, que difiere de PL/SQL en cursores, manejo de excepciones, paquetes y funciones específicas de Oracle.
Herramientas como ora2pg manejan la conversión estructural.
La lógica procedural — especialmente los casos extremos de manejo de excepciones y la coerción implícita de tipos — requiere revisión manual y reescritura.

¿Qué sucede con los niveles de rendimiento de Oracle después de migrar a PostgreSQL?

El rendimiento después de la migración depende en gran medida de la optimización de consultas. Las pistas específicas de Oracle, el uso de ROWNUM y el manejo implícito de tipos no se traducen directamente.
Después de una adecuada optimización del rendimiento de PostgreSQL, las consultas suelen ejecutarse con un rendimiento comparable o mejor que el original de Oracle.
Las ganancias son más visibles en cargas de trabajo intensivas de E/S, donde el modelo MVCC de PostgreSQL y las opciones de indexación flexibles funcionan bien.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *