Pg_lake - extensión que admite acceso a Iceberg y data lakes desde Postgres

 (github.com/Snowflake-Labs)
3 puntos por GN⁺ 2025-11-05 | 1 comentarios | Compartir por WhatsApp
  • pg_lake es una extensión basada en Postgres que integra directamente tablas Iceberg y archivos de data lake para ofrecer transacciones y consultas de alta velocidad
  • Permite consultar, importar y exportar directamente archivos Parquet, CSV, JSON e Iceberg en almacenamiento de objetos como S3
  • Aprovecha internamente el motor de consultas DuckDB para asegurar un rendimiento de ejecución rápido dentro del entorno de Postgres
  • Ofrece en una sola interfaz SQL funciones de lakehouse de datos como creación de tablas Iceberg, inferencia automática de esquema para archivos externos y entrada/salida con S3 mediante el comando COPY
  • Tras la adquisición de Crunchy Data por parte de Snowflake en 2025, fue liberado como código abierto, sentando una base para ampliar la integración con data lakes en el ecosistema de Postgres

Resumen de pg_lake

  • pg_lake es una extensión que integra Iceberg y archivos de data lake en Postgres, lo que permite usar Postgres como un sistema lakehouse independiente
    • Garantiza transacciones y consultas rápidas sobre tablas Iceberg
    • Permite acceso directo a archivos de datos sin procesar en almacenamiento de objetos como S3
  • Funciones principales
    • Crear y modificar tablas Iceberg, y consultarlas desde otros motores
    • Consultar e importar archivos de datos en formatos Parquet, CSV, JSON e Iceberg
    • Exportar resultados de consultas al almacenamiento de objetos en formatos Parquet, CSV y JSON mediante el comando COPY
    • Leer formatos de datos geoespaciales compatibles con GDAL, como GeoJSON y Shapefile
    • Proporcionar un tipo map integrado para datos semiestructurados
    • Combinar heap, Iceberg y archivos externos en una sola consulta SQL
    • Inferir automáticamente columnas y tipos desde fuentes de datos externas
    • Ejecución rápida mediante el motor DuckDB

Instalación y configuración

  • Métodos de instalación
    • Ejecución sencilla con Docker
    • Instalación manual o preparación de entorno de desarrollo mediante compilación desde el código fuente
  • Ejemplo de creación de la extensión 
    CREATE EXTENSION pg_lake CASCADE;
    • Extensiones relacionadas: pg_lake_table, pg_lake_engine, pg_extension_base, pg_lake_iceberg, pg_lake_copy
  • pgduck_server
    • Proceso independiente que implementa el protocolo wire de Postgres y usa DuckDB internamente
    • Funciona en el puerto predeterminado 5332 y permite conexión directa con psql
    • Configuraciones principales
      • --memory_limit: límite de memoria (80% de la memoria del sistema por defecto)
      • --init_file_path: especifica el archivo SQL que se ejecutará al iniciar
      • --cache_dir: especifica el directorio de caché para archivos remotos
  • Configuración de conexión a S3
    • Usa el secrets manager de DuckDB para reconocer automáticamente credenciales de AWS/GCP
    • Ejemplo para especificar la ubicación de almacenamiento de tablas Iceberg 
      SET pg_lake_iceberg.default_location_prefix TO 's3://testbucketpglake';

Ejemplos de uso

  • Crear una tabla Iceberg 
    CREATE TABLE iceberg_test USING iceberg AS   
SELECT i as key, 'val_'|| i as val FROM generate_series(0,99)i;
    • Después de crearla, SELECT count(*) FROM iceberg_test; devuelve 100
    • Se puede verificar la ubicación de los metadatos de Iceberg
  • Entrada/salida con COPY hacia S3 
    COPY (SELECT * FROM iceberg_test) TO 's3://.../iceberg_test.parquet';  
COPY iceberg_test FROM 's3://.../iceberg_test.parquet';
    • Compatibilidad con formatos Parquet, CSV y JSON
  • Crear una tabla externa desde archivos en S3 
    CREATE FOREIGN TABLE parquet_table()   
SERVER pg_lake   
OPTIONS (path 's3://.../*.parquet');
    • Inferencia automática de columnas y posibilidad de consulta (SELECT count(*) FROM parquet_table; → 100)

Arquitectura

  • Componentes
    • PostgreSQL + extensión pg_lake
    • pgduck_server (ejecución de DuckDB e implementación del protocolo de Postgres)
  • Modo de operación
    • El usuario se conecta a Postgres y ejecuta SQL
    • Parte de las consultas se ejecuta mediante DuckDB con procesamiento paralelo y orientado a columnas
    • Al no embeber DuckDB dentro del proceso de Postgres, se evitan problemas de seguridad de hilos y memoria
    • Es posible acceder directamente al motor DuckDB mediante clientes estándar de Postgres

Lista detallada de componentes

  • pg_lake_iceberg: implementación de la especificación Iceberg
  • pg_lake_table: implementación de FDW para archivos en almacenamiento de objetos
  • pg_lake_copy: soporte de entrada/salida COPY hacia el data lake
  • pg_lake_engine: módulo común
  • pg_extension_base: componente base para otras extensiones
  • pg_extension_updater: función de actualización automática de extensiones
  • pg_lake_benchmark: ejecución de benchmarks para tablas de lake
  • pg_map: generador generalizado de tipo map
  • pgduck_server: servidor que carga DuckDB y lo expone mediante el protocolo de Postgres
  • duckdb_pglake: agrega funciones compatibles con Postgres a DuckDB

Desarrollo e historial de publicación

  • El desarrollo comenzó a inicios de 2024 en Crunchy Data para incorporar Iceberg a Postgres
  • Al principio se centró en la integración con DuckDB y en ofrecer funciones para clientes de Crunchy Bridge
  • Después se implementaron el protocolo Iceberg v2 y el soporte de transacciones
  • En noviembre de 2024 fue relanzado como Crunchy Data Warehouse
  • En junio de 2025, Snowflake adquirió Crunchy Data, y en noviembre de 2025 pg_lake fue liberado como código abierto
    • La versión inicial es la 3.0 (incluye las dos generaciones anteriores)
    • Los usuarios existentes de Crunchy Data Warehouse cuentan con una ruta de actualización automática

Licencia y dependencias

  • Licencia Apache 2.0
  • Depende de los proyectos Apache Avro y DuckDB
    • Durante la compilación se aplican parches a las extensiones de Avro y DuckDB

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-11-05
Opiniones de Hacker News
  • Me pregunto si habrá alguna razón para no usar simplemente Ducklake
    Así se puede reducir la complejidad. Solo se necesitan DuckDB y PostgreSQL (pg_duckdb)
    Como referencia, también está el video de la charla del Prof. Hannes Mühleisen: DuckLake - The SQL-Powered Lakehouse Format for the Rest of Us
    • DuckLake es un proyecto bastante genial. A nuestro equipo también le gusta DuckDB. De hecho, pg_lake fue posible gracias a DuckDB
      DuckLake puede hacer cosas que pg_lake basado en Iceberg no puede, y a la vez Postgres puede hacer cosas que DuckDB no puede. Por ejemplo, puede manejar más de 100 mil inserciones de una sola fila por segundo
      El procesamiento transaccional no sale gratis. En vez de poner el motor dentro del catálogo, si pones el catálogo dentro del motor, se vuelven posibles las transacciones entre tablas analíticas y operativas
      Postgres también resulta natural en términos de persistencia y procesamiento continuo. Se puede construir orquestación con pg_cron y PL/pgSQL
      Además, Iceberg también tiene como fortaleza la interoperabilidad con múltiples motores de consulta
    • Al final, es una cuestión de decisiones de diseño. Se puede ver una discusión relacionada en este hilo
    • Yo también intenté con muchas ganas que me encantara Ducklake, pero al usarlo de verdad tuve problemas de mantenimiento. En especial con el catálogo de pg, a veces Ducklake lanzaba errores HTTP 400 sobre archivos que él mismo generaba
      No estoy seguro de si fue por mi patrón de escritura de datos (insertar desde un DataFrame de Polars a una tabla Ducklake) o por la estructura de tablas particionadas
      En entorno de desarrollo/pruebas estaba bien, pero para todo el equipo hubo dificultades. Así que al final volvimos a una combinación de archivos Parquet particionados con Hive y vistas de DuckDB
      Más adelante pienso subir un ejemplo como issue, pero ahora no me da el tiempo por otros temas
  • Esto sí es un gran cambio
    Antes se decía que en el mercado de Postgres no existía un “Snowflake open source”
    La extensión de Postgres de Crunchy es la solución más adelantada del mercado en este momento. Felicidades a Snowflake y al equipo de Crunchy por haberlo publicado como open source
    • Si soy sincero, creo que conviene más simplemente pagar por Snowflake y aprovechar esa gran base de datos y su ecosistema. Si la infraestructura no es parte central del valor para el cliente, mejor delegar esa parte y enfocarse en construir algo genial
  • Me gustan los data lakes y los lenguajes de consulta tipo SQL. Se siente como una evolución de la filosofía de “todo es un archivo”
    En Linux puedes leer y escribir la configuración del sistema a través del sistema de archivos (cat /sys/..., echo ... > /sys/...)
    Con FUSE puedes implementar directamente un driver de sistema de archivos en espacio de usuario. Por ejemplo, puedes montar SSH o Google Drive y copiar con el comando cp
    Pero los sistemas de archivos solo son adecuados para datos jerárquicos. La mayoría de los datos del mundo real tienen una estructura relacional
    Los data lakes permiten tratar distintas fuentes de datos como si fueran una sola base de datos relacional mediante la elegante abstracción de SQL
    Al final, muchas aplicaciones giran en torno a CRUD, así que este enfoque es mucho más eficiente
  • ¿Cómo usas tú un data lake? Para mí no es solo almacenamiento, sino un espacio para trabajos analíticos impredecibles
    En esos casos, Postgres tiene límites. Hace falta más CPU y RAM, y al final se necesita un motor distribuido
    • La clave del data lake es la separación entre cómputo y almacenamiento. Postgres no es la capa de cómputo, sino la capa de acceso
      El cómputo le pregunta a Postgres cosas como “¿cuáles son los datos actuales de estas claves?” o “¿cuáles eran los datos de hace 2 semanas?”, y las consultas analíticas reales se ejecutan directamente sobre archivos Parquet
  • Cuando Snowflake adquirió Crunchy Data, esperaba que ofrecieran una versión administrada de esto
    Está bueno poder correrlo en Docker local, pero estaría mejor poder operarlo en AWS con facturación integrada a una cuenta de Snowflake
  • De verdad siento que ahora mismo estamos en la edad dorada de PostgreSQL
  • No soy ingeniero de datos, pero trabajo en un área relacionada. Me pregunto si alguien podría explicar fácil qué problema resuelve esto
    • Por ejemplo, supongamos que un servicio va acumulando datos de logs en archivos Parquet en S3. Si quieres consultar esos datos directamente desde Postgres, pg_lake resulta útil
      Puedes cargar los datos Parquet en Postgres para consultarlos, y también hacer joins con tablas existentes
  • Tengo dos preguntas
    (1) ¿Hay planes de compatibilidad para usar la especificación de Ducklake en lugar de Iceberg? Ducklake administra el catálogo con tablas SQL en vez de archivos, así que la escritura concurrente y la gestión de snapshots son más simples
    (2) ¿Existe la posibilidad de que pg_duckdb termine haciendo lo mismo con el tiempo?
    • (1) Lo consideramos, pero por ahora no hay planes. Más que usar Ducklake tal cual, queremos implementarlo directamente dentro de Postgres para mantener los límites transaccionales
      Aun así, hay complejidades como el procesamiento de datos inline. Si eso se resuelve, se puede obtener un alto rendimiento transaccional
      (2) Para pg_duckdb sería más fácil reutilizar la implementación de Ducklake, pero desde el punto de vista de la gestión de recursos y la estabilidad, creo que esa estructura es menos adecuada
  • Viendo S3 Table Buckets, Cloudflare R2 Data Catalog y ahora este proyecto, da la impresión de que Iceberg está ganando
  • Si quieres cargar datos fácilmente en una BD compatible con Postgres Wire, recomiendo sling-cli
    Puedes ejecutar trabajos ETL con CLI, YAML o Python