Postgres sobre Parquet en S3: arquitectura LTAP

Durante años, la decisión fue bastante simple: si querías transacciones rápidas, usabas una base de datos relacional; si querías analítica barata, mandabas los datos a un data warehouse o a un lake. El problema es que esa separación te obliga a duplicar datos, mantener pipelines y aceptar que una parte del sistema siempre va a ir un paso atrás. Si tu equipo opera en nube, probablemente ya pagaste esa factura en complejidad, latencia y almacenamiento.

La propuesta de Postgres sobre Parquet en S3 apunta justamente a eso: separar el almacenamiento de la capa de cómputo, pero sin romper la experiencia de Postgres para el día a día. La idea de LTAP, como la plantea Databricks en su artículo sobre Lakebase, es mover el almacenamiento a archivos Parquet sobre S3 y dejar que la base siga sirviendo consultas transaccionales y analíticas con una arquitectura híbrida. No se trata de reemplazar Postgres por un lake, sino de replantear dónde vive cada tipo de dato y cuánto cuesta moverlo.

Qué problema intenta resolver LTAP

El problema no es nuevo. En un stack clásico, tu aplicación escribe en Postgres, luego un proceso ETL o CDC replica esos datos a un warehouse, y después el equipo de BI consulta otra copia. Eso funciona, pero tiene tres costos claros: más infraestructura, más latencia y más puntos de falla. Si tienes una operación con miles de escrituras por minuto y reportes que llegan con retraso, sabes que esa separación termina pegándote en el negocio.

LTAP, o “lakehouse transactional and analytical processing”, intenta reducir esa fractura. La idea es que el mismo dato pueda servir para transacciones y análisis sin obligarte a mantener dos sistemas con copias divergentes. En vez de pensar en una base cerrada con su propio disco local, piensas en Postgres como una capa de acceso sobre almacenamiento de objetos, en este caso S3, con Parquet como formato de persistencia analítica.

Eso cambia varias decisiones de arquitectura. Ya no dependes tanto de discos adjuntos a una instancia específica, ni de escalar la base solo para aguantar más storage. También abre la puerta a un patrón más flexible para workloads mixtos, donde una app necesita responder rápido a escrituras, pero al mismo tiempo un analista quiere consultar millones de filas sin castigar la carga transaccional.

La separación entre storage y compute

La parte más relevante de esta idea es la separación entre almacenamiento y cómputo. En un Postgres tradicional, el motor administra sus páginas en disco y la instancia que corre la base también carga con el peso del storage. En una arquitectura sobre S3, el almacenamiento vive en un servicio de objetos y el motor puede enfocarse más en ejecutar consultas, gestionar cachés y coordinar concurrencia.

Eso no elimina la complejidad, la cambia. Ahora tienes que pensar en latencia de red, en formatos columnar como Parquet, en cachés locales y en cómo sincronizar cambios sin perder consistencia. Pero a cambio puedes escalar storage con mucha más flexibilidad y, en algunos casos, reducir el costo de mantener datos históricos o fríos.

Por qué Parquet y no solo archivos de Postgres

Parquet no está ahí por moda. Es un formato columnar pensado para analítica, compresión eficiente y lecturas selectivas. Si un reporte necesita solo 5 columnas de una tabla de 80, Parquet permite leer mucho menos dato que un formato fila por fila. Para cargas analíticas, eso importa bastante.

La apuesta de LTAP es que Postgres pueda convivir con ese formato sin perder su identidad transaccional. En otras palabras, la base no deja de ser Postgres, pero el almacenamiento subyacente deja de ser el clásico disco local administrado por una sola instancia. Ese cambio puede ser útil para equipos que quieren una sola capa lógica de datos, con menos copias y menos trabajo de sincronización.

Cómo funciona una arquitectura híbrida sobre S3

La arquitectura híbrida no significa que todo se vaya a S3 de forma ingenua. Significa que ciertas partes del sistema siguen optimizadas para escritura y transacción, mientras otras se apoyan en almacenamiento columnar para consultas más pesadas. En la práctica, eso suele implicar una combinación de caché, metadatos, archivos compactados y coordinación entre capas.

Piensa en un flujo así: la aplicación escribe una orden de compra, el sistema confirma la transacción, y esa información termina persistida en Parquet sobre S3. Después, cuando un dashboard necesita sumar ventas por país, el motor consulta los archivos adecuados y evita recorrer todo el historial de forma innecesaria. No es magia, es un diseño que intenta alinear el tipo de almacenamiento con el tipo de acceso.

Esto también cambia cómo observas el costo. En vez de pagar por una instancia sobredimensionada solo para tener más disco, puedes separar el crecimiento del almacenamiento del crecimiento de la capacidad de cómputo. Para equipos en LatAm, donde el presupuesto de nube suele ser más sensible al tipo de cambio y a la demanda variable, esa separación puede ser bastante útil.

Qué pasa con la consistencia

La pregunta obvia es: si el storage está en S3 y el formato es Parquet, ¿cómo evitas que una consulta lea datos incompletos? La respuesta depende del diseño concreto de la capa de metadatos y del mecanismo de commits. Según la documentación oficial de S3, el servicio ofrece durabilidad alta y consistencia fuerte para objetos nuevos y sobreescrituras, pero eso no resuelve por sí solo la coordinación de una base de datos; esa parte sigue siendo responsabilidad del motor y su protocolo de escritura. Puedes revisar la documentación de Amazon S3 aquí: https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html

En otras palabras, el reto no es solo guardar archivos. El reto es garantizar que una transacción quede visible solo cuando está completa, que los lectores no vean estados intermedios y que el sistema pueda recuperarse si algo falla. Ahí es donde una arquitectura tipo LTAP necesita metadatos sólidos, control de versiones y una estrategia clara de commit.

Qué significa para el ciclo de lectura

En un sistema híbrido, no todas las lecturas son iguales. Algunas van a la caché o a estructuras optimizadas para OLTP; otras van directo a Parquet en S3. Eso permite responder rápido a consultas pequeñas y, al mismo tiempo, sostener consultas de agregación más grandes sin forzar la misma ruta de acceso para todo.

Para que eso funcione bien, el motor necesita saber qué bloques o archivos tocar. Si no tiene buen pruning de particiones, índices de metadatos o estadísticas actualizadas, el beneficio se diluye. Por eso esta arquitectura no es solo una decisión de almacenamiento; también es una decisión de diseño del motor.

Qué gana tu equipo y qué pierde

La ventaja más visible es la reducción de duplicación. Si hoy mantienes Postgres para la operación y otro sistema para analítica, seguramente estás moviendo datos con CDC, jobs programados o pipelines de transformación. Eso agrega latencia y mantenimiento. Con una base apoyada en Parquet sobre S3, podrías acercar más la capa operativa y la analítica, al menos para ciertos casos de uso.

Otra ganancia es la elasticidad. S3 escala sin que tengas que redimensionar volúmenes o migrar discos. Eso ayuda cuando el crecimiento de datos no sigue el mismo ritmo que el crecimiento de consultas. También puede simplificar la retención de históricos, porque almacenar terabytes en objetos suele ser más barato que mantenerlos en storage de instancia.

Pero no todo es ventaja. Hay compromisos claros. El acceso a S3 tiene más latencia que un disco local. Si tu workload depende de escrituras ultrabajas en milisegundos constantes, tienes que medir muy bien. Además, Parquet es excelente para analítica, pero no siempre es la mejor opción para cada patrón transaccional. La arquitectura funciona si aceptas que el motor va a usar diferentes caminos para diferentes tipos de acceso.

Casos donde sí tiene sentido

• Aplicaciones SaaS con muchas escrituras y reportes operativos diarios.
• Plataformas de e-commerce que necesitan ver ventas casi en tiempo real, pero también analizar histórico por país, SKU o canal.
• Fintechs que manejan transacciones y luego generan agregados para riesgo, fraude o conciliación.
• Equipos que quieren reducir la copia entre OLTP y BI sin montar un stack demasiado grande.

Casos donde no conviene forzarlo

• Sistemas con dependencias fuertes de baja latencia constante y sin margen para variación de red.
• Aplicaciones pequeñas donde el costo de complejidad supera el ahorro de storage.
• Workloads donde el patrón principal es escritura aleatoria muy intensa y poco análisis.

Cómo se ve esto en la práctica

Supón una empresa de pagos en Ciudad de México o Quito. Tiene una tabla de transacciones que crece 50 millones de filas al mes. Hoy guarda eso en Postgres, replica a un warehouse y mantiene dashboards de fraude y negocio por separado. Cada vez que cambia el esquema, hay que tocar dos o tres capas. Cada vez que se retrasa un job, los reportes llegan tarde.

Con una arquitectura híbrida, podrías mantener la experiencia de Postgres para la app y persistir el almacenamiento en Parquet sobre S3. Los reportes operativos podrían leer el mismo origen lógico, mientras la capa analítica consulta archivos ya organizados para ese propósito. No desaparece el trabajo de ingeniería, pero sí puedes reducir el número de copias y el tiempo entre un evento y su disponibilidad para análisis.

Una forma de verlo es esta tabla comparativa:

La tabla no pretende decir que una opción siempre gana. Solo muestra que el diseño híbrido cambia el balance. Si tu equipo valora más simplificar la duplicación y aceptar una capa de coordinación más sofisticada, LTAP puede tener sentido. Si necesitas simplicidad extrema, quizá no.

Qué mirar antes de adoptarlo

1. Latencia real de tus consultas más frecuentes, no la media general.
2. Tamaño y crecimiento mensual de datos, en GB o TB.
3. Porcentaje de consultas analíticas sobre el total.
4. Costo de mover datos entre sistemas hoy.
5. Dependencia de tu app respecto a lecturas ultra rápidas y consistentes.

Si respondes esas cinco preguntas con números, vas a saber bastante rápido si el cambio puede ayudarte o solo te agrega una capa nueva de complejidad.

Implicaciones para cloud y equipos en LatAm

En Latinoamérica, muchas decisiones de arquitectura no se toman solo por elegancia técnica. También pesan el costo en dólares, la variabilidad de carga y el tamaño del equipo. Una solución que reduce duplicación y mejora la reutilización de datos puede liberar tiempo de ingeniería para tareas más cercanas al producto.

Además, hay un punto práctico: cuando tu operación crece en varios países, el dato deja de ser solo una tabla. Empiezas a necesitar históricos por moneda, país, canal y regulación. Mantener copias separadas en varios sistemas se vuelve caro. Una arquitectura como LTAP puede ayudar a centralizar la persistencia y simplificar el acceso, siempre que el motor y la gobernanza estén bien diseñados.

También hay un ángulo de resiliencia. S3 y otros object stores suelen ser parte del estándar de infraestructura en nube, y eso facilita estrategias de recuperación y retención. Pero no confundas durabilidad del almacenamiento con diseño de aplicación. Tu aplicación sigue necesitando observabilidad, backups, pruebas de recuperación y control de acceso. La arquitectura híbrida no reemplaza esas prácticas.

Para entender mejor el contexto técnico, también puedes revisar la documentación oficial de PostgreSQL sobre almacenamiento y MVCC: https://www.postgresql.org/docs/current/mvcc.html. No porque LTAP copie exactamente el modelo tradicional, sino porque te ayuda a comparar qué se conserva y qué cambia cuando separas storage y compute.

Qué debes evaluar si quieres probar algo parecido

Antes de pensar en migración, conviene separar expectativa de realidad. No todo lo que suena bien en arquitectura se traduce en un corte limpio. Si hoy tu sistema depende de extensiones, triggers complejos o consultas muy específicas, la compatibilidad importa tanto como el rendimiento. Una arquitectura híbrida tiene que respetar el comportamiento que tu app ya espera.

También necesitas medir el costo de la consulta analítica frente al costo del almacenamiento. Si tus dashboards se refrescan cada 5 minutos y consultan solo una ventana pequeña, quizá el ahorro está en otra parte. Si guardas años de histórico y casi nunca tocas los datos fríos, ahí sí el modelo sobre S3 puede empezar a brillar.

Preguntas concretas para tu equipo

• ¿Cuánto tarda hoy un reporte que cruza transacciones y agregados por día?
• ¿Cuántas copias del mismo dato existen entre OLTP, ETL y BI?
• ¿Qué parte del storage está realmente activa en los últimos 30 días?
• ¿Cuánto te cuesta mantener pipelines solo para sincronizar datos?
• ¿Tu equipo necesita escalar cómputo, storage o ambos?

Si no tienes estas respuestas, empezar por una prueba pequeña es mejor que una migración grande. Un piloto con una sola tabla o un dominio acotado te da señales más útiles que una discusión teórica.

Tabla resumen

La idea central de Postgres sobre Parquet en S3 no es venderte una base mágica. Es obligarte a repensar el lugar que ocupa el storage en tu arquitectura. Si el dato ya vive en la nube, quizá vale la pena dejar de tratar el disco como el centro del sistema y empezar a verlo como una capa más, diseñada según el tipo de acceso que realmente tienes.