Muchas empresas que migran de Oracle a PostgreSQL asumen que el principal reto será Diferencias de sintaxis SQL.
Pero en realidad, los mayores cambios son arquitectura.
Si procede de un entorno Oracle (RAC, Exadata, entornos Enterprise), comprender estas diferencias es esencial porque afectan directamente:
- Ajuste del rendimiento
- Solución de problemas
- Planificación de capacidades
- Estrategias de ampliación
A continuación 8 diferencias arquitectónicas clave entre Oracle y PostgreSQL que más afectan al rendimiento.
Índice
1. Modelo de proceso
Oracle: Arquitectura de memoria compartida
Oracle depende en gran medida de estructuras de memoria compartida dentro del SGA (Área Global del Sistema).
Arquitectura típica:
User process
|
Server process
|
SGA (shared memory)
Los componentes clave del SGA incluyen:
SGA
├ Buffer cache
├ Shared pool
├ Redo log buffer
└ Large pool
Muchas sesiones acceden al mismas estructuras de memoria simultáneamente.
Para controlar la concurrencia Oracle utiliza mecanismos como:
- Pestillos
- Mutexes
- Bloqueos de caché de biblioteca
PostgreSQL: Process-Per-Connection
PostgreSQL utiliza un arquitectura de procesos por conexión.
Client
|
PostgreSQL backend process
Cada conexión genera un proceso OS independiente.
Por ejemplo:
postgres
├ backend process 1
├ backend process 2
├ backend process 3
La memoria compartida es más pequeña y sencilla.
Las principales áreas compartidas incluyen:
shared_buffers
wal_buffers
Impacto en el rendimiento
PostgreSQL no puede manejar eficientemente miles de conexiones directas.
Es por eso que los poolers de conexión como:
pgBouncer
pgpool
se utilizan habitualmente en la producción.
2. Control de concurrencia (MVCC)
Tanto Oracle como PostgreSQL utilizan MVCC (Control de concurrencia multiversión), pero lo aplican de forma diferente.
Oracle MVCC
Oracle almacena las versiones anteriores de las filas en UNDO tablespaces.
Ejemplo de operación:
UPDATE table
Oracle escribe la versión anterior en:
UNDO
Cuando una consulta necesita una instantánea más antigua, Oracle la reconstruye utilizando UNDO.
PostgreSQL MVCC
Almacenes PostgreSQL versiones de fila directamente dentro de la tabla.
Ejemplo de actualización:
UPDATE row
PostgreSQL crea un nueva versión de la fila.
old row (dead)
new row (visible)
Impacto en el rendimiento
Dado que las versiones antiguas de las filas permanecen dentro de las tablas, las tablas PostgreSQL crecen con el tiempo.
Es por eso que PostgreSQL requiere:
VACUUM
Sin una limpieza adecuada se obtiene:
table bloat
index bloat
Este es uno de los mayores diferencias conceptuales para los DBA de Oracle.
3. VACUUM frente a Oracle Automatic Cleanup
Oracle gestiona automáticamente las versiones antiguas de las filas mediante el sistema UNDO.
PostgreSQL requiere una limpieza periódica mediante VACÍO.
Existen dos tipos principales:
VACUUM
AUTOVACUUM
Autovacuum elimina automáticamente las tuplas muertas.
Si el autovacío no está bien ajustado puede experimentar:
table bloat
slow sequential scans
very large indexes
Implicación en el rendimiento
En entornos PostgreSQL:
autovacuum tuning is critical
Muchos problemas de producción tienen su origen en:
autovacuum not aggressive enough
4. WAL vs Oracle Redo Logs
Ambos sistemas utilizan registro de escritura anticipada para la recuperación de accidentes.
Registro de Oracle
Oracle utiliza redo logs.
Los cambios fluyen:
redo log buffer
→ redo log files
Responsable del proceso de fondo:
LGWR
Registro PostgreSQL
PostgreSQL utiliza WAL (registro de escritura anticipada).
Los datos se escriben en:
WAL segments
Ubicación:
pg_wal/
Archivo de ejemplo:
00000001000000000000000A
Implicación en el rendimiento
El rendimiento de PostgreSQL depende a menudo de:
WAL throughput
disk latency
checkpoint tuning
Entre los parámetros importantes figuran:
checkpoint_timeout
max_wal_size
wal_buffers
5. Comportamiento del índice
Los índices de Oracle permanecen relativamente estables incluso bajo fuertes actualizaciones.
Los índices PostgreSQL se comportan de forma diferente debido a MVCC.
Cuando se actualiza una fila:
UPDATE row
PostgreSQL crea:
new row version
new index entry
La entrada de índice anterior permanece hasta que se ejecuta el vacío.
Implicación en el rendimiento
Los índices PostgreSQL pueden hincharse significativamente.
Puede requerir un mantenimiento periódico:
REINDEX
VACUUM FULL
O vistas de control como:
pg_stat_all_indexes
6. Diferencias del optimizador de consultas
Oracle dispone de un optimizador extremadamente sofisticado con funciones como:
adaptive plans
parallel query
optimizer hints
statistics feedback
El optimizador de PostgreSQL es más sencillo y se basa principalmente en:
statistics
cost model
Las estadísticas se almacenan en:
pg_statistic
Actualizado a través de:
ANALYZE
Implicación en el rendimiento
En PostgreSQL:
bad statistics = bad execution plans
Por eso autovacío analizar es importante.
7. Ejecución paralela
La consulta paralela de Oracle es muy avanzada.
Por ejemplo:
SELECT /*+ PARALLEL(8) */ ...
PostgreSQL añadió el paralelismo más tarde.
Las operaciones más comunes son:
Parallel Seq Scan
Parallel Hash Join
Parallel Aggregate
Controlado por parámetros como:
max_parallel_workers_per_gather
max_worker_processes
Implicación en el rendimiento
El paralelismo en PostgreSQL es menos agresivo que Oracle, pero sigue siendo valioso para:
large analytical queries
8. Arquitectura de clústeres
Aquí es donde Oracle y PostgreSQL difieren más.
Oracle RAC
Oracle RAC permite varios nodos para escribir simultáneamente.
Node1
Node2
Node3
Todos los nodos acceden al misma base de datos compartida.
Replicación PostgreSQL
PostgreSQL utiliza un arquitectura de un solo escritor.
Primary
|
Standby replicas
Los métodos de replicación incluyen:
streaming replication
logical replication
Implicación en el rendimiento
Las estrategias de ampliación difieren significativamente.
Escalado de Oracle RAC:
add nodes → more write capacity
Escalado PostgreSQL:
read scaling → replicas
write scaling → sharding
Resumen de arquitectura Oracle vs PostgreSQL
| Característica | Oracle | PostgreSQL |
|---|---|---|
| Modelo de proceso | hilos/memoria compartida | proceso por conexión |
| MVCC | UNDO | versiones de fila |
| Limpieza | automático | VACÍO |
| Registro | rehacer | WAL |
| Comportamiento del índice | estable | puede hincharse |
| Optimizador | complejo | más sencillo |
| Consulta paralela | muy avanzado | moderado |
| Agrupación | RAC | replicación |
Las 3 cosas que más sorprenden a los DBA de Oracle
Durante las migraciones reales, estos tres problemas aparecen con frecuencia.
1. Problemas de autovacío
Síntomas:
tables growing
indexes growing
slow queries
2. Demasiadas conexiones
PostgreSQL no escala bien con grandes recuentos de conexiones.
1000+ connections
La solución típica es:
pgBouncer
3. Cuellos de botella de la WAL
Las cargas de trabajo con mucha escritura pueden saturar:
WAL disk throughput
Reflexiones finales
Migrar de Oracle a PostgreSQL no es sólo traducir SQL.
Requiere comprender diferencias arquitectónicas fundamentales que influyen en el rendimiento, la ampliación y las prácticas operativas.
Una vez comprendidas estas diferencias, PostgreSQL se convierte en una plataforma extremadamente potente y flexible para los sistemas de datos modernos.