De Oracle a PostgreSQL: Historia de Gwen Shapira 2026

Gwen Shapira recorrió un camino poco común en arquitectura de datos: pasó de operar Oracle a escala empresarial, se sumergió años en NoSQL (Hadoop, Kafka), y finalmente co-fundó Nile, una plataforma que reinventa PostgreSQL para SaaS moderno. Su experiencia en el episodio 38 de Talking Postgres revela por qué PostgreSQL se convirtió en su apuesta, qué fallaba en Oracle y NoSQL, y cuándo tiene realmente sentido migrar.

¿Quién es Gwen Shapira y por qué su experiencia importa?

Gwen Shapira es una arquitecta de datos con más de 20 años de experiencia en sistemas de bases de datos — nada de “especialista en bases de datos modernas”, es alguien que pasó dos décadas viendo cómo fallan los sistemas cuando los presionas. Co-fundadora de Nile, una plataforma construida sobre PostgreSQL. Antes fue ingeniera destacada en Confluent trabajando con Kafka, y antes de eso pasó años operando Hadoop y Oracle en empresas que manejaban volúmenes de datos que podrían asustar a cualquiera.

Por qué importa su voz: Gwen no es vendedor de PostgreSQL. Es alguien que lo rechazó durante años, que confió en Oracle, que creyó en NoSQL, y que cambió de opinión porque vio cosas que no se arreglan con marketing. Eso es confiable.

El comienzo: operando Oracle a escala

Oracle fue su primer hogar profesional en bases de datos. Y funcionaba. Ponele que necesitabas garantías ACID en una transacción de comercio electrónico — Oracle te lo daba. Necesitabas que los índices fueran predecibles — Oracle tenía herramientas sofisticadas para eso. Oracle dominaba el mercado empresarial porque sus administradores de base de datos sabían exactamente qué estaba pasando en cada query.

Pero Oracle tenía un problema incómodo: el costo y la rigidez. Si querías cambiar un esquema, eras cuidadoso. Si querías escalar horizontalmente (distribuir datos entre máquinas), Oracle no lo hacía con gracia. Era vertical: una máquina cada vez más grande, cada vez más cara (spoiler: nunca es lo suficientemente grande).

El desvío NoSQL: flexibilidad que costó caro

Ahí llegó NoSQL prometiendo el cielo: sin esquemas rígidos, escalabilidad horizontal fácil, velocidad (si es que eso cuenta como mejora). MongoDB. Cassandra. HBase. Gwen se sumergió. Hadoop, Kafka — toda la pila de datos distribuidos del momento. Y resolvía cosas: podías agregar campos sin migraciones masivas, distribuías datos sin suplicios.

Excepto que después te despertabas a las 3 de la mañana con un problema: dos clientes tenían el mismo ID en tu base de datos porque nada garantizaba unicidad, o los datos de un usuario estaban en tres máquinas diferentes y una se cayó, o escribiste una query que se suponía consultaría 10 registros y terminó tocando todo el cluster. Te puede servir nuestra cobertura de testear cambios en tu ambiente local.

Lo que NoSQL no podía ofrecer era lo que Oracle se había pasado 30 años haciendo obsesivamente: garantías. ACID. Consistencia. Las relaciones entre tablas. El valor está en que alguien piense por vos: “este dato solo puede coexistir con este otro, siempre”.

La redescubierta: por qué PostgreSQL tenía razón

PostgreSQL no es nuevo. Lleva 30 años en existencia (celebró eso recién en 2026). Pero para Gwen fue un redescubrimiento: aquí estaban las garantías de Oracle, la flexibilidad que prometía NoSQL, y una comunidad obsesionada con documentar absolutamente todo hasta el hartazgo (si googleás un problema de Postgres, alguien escribió un blog post de 5000 palabras al respecto, y es exactamente tu problema).

PostgreSQL tiene features como Transaction Isolation que te permiten controlar exactamente cómo se comportan las transacciones concurrentes. Tiene tipos de datos JSON si querés flexibilidad al nivel de columna. Tiene índices que funcionan. Tiene una comunidad que en vez de vender, simplemente ayuda.

El punto es que PostgreSQL respeta los principios fundamentales de Codd (la teoría relacional) pero sin la pompa de Oracle. Es pragmático. Si necesitás un arreglo rápido, lo hacés. Si necesitás que sea correcto, PostgreSQL tiene los mecanismos para lograrlo.

Nile: PostgreSQL rediseñado para SaaS moderno

PostgreSQL es excelente, pero tiene un problema inherente: fue diseñado para una máquina, no para cien clientes en la nube. Nile es la respuesta de Gwen a eso.

Nile es una plataforma que construye multi-tenancia nativa sobre PostgreSQL — significa que varias empresas (tenants) comparten la misma instancia pero sus datos están totalmente aislados, y podés escalar cada tenant sin tocar a los otros. Algo que PostgreSQL vanilla no hace. Para más detalles técnicos, mirá proteger datos sensibles en migraciones.

Además, Nile es serverless: no pensás en máquinas, pagas por lo que usás, y escala automáticamente cuando un cliente tiene un pico. Es lo que Oracle nunca fue, y lo que NoSQL prometía pero no entregaba con seguridad. Gwen vio que PostgreSQL era el kernel correcto, pero necesitaba una capa encima que lo hiciera apto para 2026.

Cuándo tiene sentido migrar (y cuándo no)

Gwen no dice “sacá Oracle mañana”. Lo que dice es más matizado. Oracle sigue siendo correcto si: operás transacciones financieras de miles de millones por día y no podés permitirte un fallo, tenés aplicaciones legacy que escribieron PL/SQL y está funcionando, o pagás DBA en tiempo completo que saben explotar cada característica.

PostgreSQL es la opción si: estás en startup o pyme, necesitás flexibilidad sin sacrificar confiabilidad, podés invertir tiempo en traducir PL/SQL a PL/pgSQL (no es copy-paste), o simplemente querés una base de datos que “just works” sin una factura de seis dígitos.

Lo incómodo es lo del medio: una migración real (no una prueba local) requiere tiempo. Traducción de código. Testing serio. Es factible, pero no es “levantá una réplica PostgreSQL y listo”. Ojo ahí.

La comunidad como factor diferencial

Gwen menciona un detail importante: la documentación de PostgreSQL es insólitamente buena. No es un doc generado automático. Alguien escribió. Ejemplos incluidos. Casuística real. Es el anti-patrón de “bueno, ahora googleá”.

Además, existen iniciativas como PostgreSQL Happiness Hints — gente dedicada a responder preguntas. Y hay eventos como PGConf.dev 2026 (mayo 19-22 en Vancouver) donde discuten cosas avanzadas como la nueva generación de features (PG20) en profundidad.

Cuando todo es open source y la comunidad se autoperpetúa porque genuinamente se preocupa, pasan cosas raras: la gente contribuye sin que les pagues. Cubrimos ese tema en detalle en versionado de scripts de migración.

Errores comunes al migrar

1. Asumir que el PL/SQL se porta igual en PL/pgSQL

No. Oracle y PostgreSQL tienen sabores de SQL procedural diferentes. Una función que funciona perfectamente en Oracle puede explotar en PostgreSQL si usás variable scope incorrecto o asumís comportamiento de casting automático que Oracle tiene pero PostgreSQL no. Testá todo.

2. Ignorar indexación

PostgreSQL no es Oracle: no “entiende automáticamente” qué índices necesitás. Si en Oracle funcionaba una query sin índice específico, en PostgreSQL puede hacer un table scan que se muere. Planificá índices explícitamente desde el inicio de la migración.

3. No medir timing antes de migrar

Sabés cuánto tarda tu query crítica en Oracle? No. Entonces cómo sabés que en PostgreSQL es más lenta o más rápida. Mide en Oracle, copia datos a PostgreSQL, mide de nuevo. Comparación justa.

Preguntas Frecuentes

¿Es PostgreSQL tan confiable como Oracle para producción?

Sí. PostgreSQL tiene ACID nativo, replicación, backup, y un track record de 30 años. Compañías que mueven exabytes de datos confían en PostgreSQL. El diferencial de Oracle no es confiabilidad hace años, es tooling premium y soporte de nivel Fortune 500. Si vos mismo podés hacer troubleshooting, PostgreSQL es tan sólido.

¿Cuánto tiempo tarda una migración realista?

Depende del tamaño y complejidad. Base de datos pequeña sin lógica procedural: 2-4 semanas. Con funciones PL/SQL complejas y aplicaciones legacy que manipulan el schema en formas raras: 3-6 meses. EnterpriseDB tiene guías detalladas que te ayudan a estimar.

¿Qué pasa con el tooling que es Oracle-específico?

Desaparece. SQL Developer, SQL*Plus, algunos plugins de monitoring — necesitás equivalentes de PostgreSQL (pgAdmin, dbeaver, Datadog, New Relic, etc.). No son cosas nuevas, pero requieren relearning. En documentar el proceso paso a paso profundizamos sobre esto.

¿PostgreSQL escala horizontalmente como NoSQL?

PostgreSQL vanilla no. Distribuir datos entre múltiples nodos requiere herramientas adicionales (Citus, CitusDB) o reimplementar tu aplicación. Nile lo hace automáticamente, pero es una capa encima. Si necesitás sharding real, NoSQL aún tiene ventaja ahí — pero con el costo de perder garantías.

¿Vale la pena migrar si Oracle está funcionando?

Si reducís costos significativamente (y los reducís: Oracle vale miles por mes, PostgreSQL en cloud cuesta fracciones), sí. Si la única razón es “PostgreSQL es moderno”, no. Oracle viejo y funcionando es mejor que PostgreSQL viejo y roto porque lo migraste mal.

Conclusión

El viaje de Gwen Shapira — Oracle → NoSQL → PostgreSQL — es una medicina contra el marketing: cada tecnología fue correcta en su momento (y aún lo es para ciertos casos). La lección no es “PostgreSQL es el futuro”, es “construí sobre lo que realmente funciona”.

PostgreSQL ganó porque respeta los fundamentos (Codd, ACID, relaciones) pero sin la pomposity de Oracle. NoSQL nos enseñó que la flexibilidad importa, y PostgreSQL lo absorbió (JSON, arrays, tipos complejos). Si estás en una pyme o startup, es tu opción por defecto. Si mantienes Oracle y funciona, no hay prisa. Si estás en SaaS moderno, Nile reinventa el juego.

La próxima vez que alguien te venda una base de datos nueva “revolucionaria”, acordate de Gwen: preguntale si tiene ACID, si tiene una comunidad que documenta, y si alguien que confías la está usando en producción hace 5 años sin quejas. Si dice sí a las tres, escuchá. Si dice no, seguí usando lo que tenés.

Fuentes

• Talking Postgres Episode 38 — How I went from Oracle to Postgres (with a big NoSQL detour)
• Astera — PostgreSQL vs Oracle: comparación detallada
• EnterpriseDB — The Complete Oracle to PostgreSQL Migration Guide
• Nile Blog — Arquitectura y features para multi-tenancia en PostgreSQL
• PGConf.dev 2026 — Conferencia oficial de PostgreSQL, mayo 19-22 en Vancouver