Pg_lake - extensão que permite acessar Iceberg e data lakes no Postgres

 (github.com/Snowflake-Labs)
3 pontos por GN⁺ 2025-11-05 | 1 comentários | Compartilhar no WhatsApp
  • pg_lake é uma extensão baseada em Postgres que integra diretamente tabelas Iceberg e arquivos de data lake, oferecendo suporte a transações e consultas de alta velocidade
  • Permite consultar, importar e exportar diretamente arquivos Parquet, CSV, JSON e Iceberg em armazenamento de objetos como S3
  • Usa internamente o mecanismo de consultas DuckDB para garantir alto desempenho de execução dentro do ambiente Postgres
  • Oferece funcionalidades de data lakehouse por meio de uma única interface SQL, como criação de tabelas Iceberg, inferência automática de esquema para arquivos externos e E/S com S3 via comando COPY
  • Após a aquisição da Crunchy Data pela Snowflake em 2025, foi lançado como open source, servindo de base para expandir a integração com data lakes no ecossistema Postgres

Visão geral do pg_lake

  • pg_lake é uma extensão que integra arquivos Iceberg e de data lake ao Postgres, permitindo usar o Postgres como um sistema lakehouse autônomo
    • Garantia de transações e consultas rápidas sobre tabelas Iceberg
    • Acesso direto a arquivos de dados brutos em armazenamento de objetos como S3
  • Principais recursos
    • Criar e modificar tabelas Iceberg, com possibilidade de consulta por outros mecanismos
    • Consultar e importar arquivos de dados nos formatos Parquet, CSV, JSON e Iceberg
    • Exportar resultados de consultas para armazenamento de objetos nos formatos Parquet, CSV e JSON com o comando COPY
    • Ler formatos de dados geoespaciais compatíveis com GDAL, como GeoJSON e Shapefile
    • Fornecer um tipo map embutido para dados semiestruturados
    • Combinar heap, Iceberg e arquivos externos em uma única consulta SQL
    • Inferir automaticamente colunas e tipos a partir de fontes de dados externas
    • Execução de alta velocidade por meio do mecanismo DuckDB

Instalação e configuração

  • Métodos de instalação
    • Execução rápida com Docker
    • Instalação manual ou configuração de ambiente de desenvolvimento via build a partir do código-fonte
  • Exemplo de criação da extensão 
    CREATE EXTENSION pg_lake CASCADE;
    • Extensões relacionadas: pg_lake_table, pg_lake_engine, pg_extension_base, pg_lake_iceberg, pg_lake_copy
  • pgduck_server
    • Processo independente que implementa o protocolo wire do Postgres e usa DuckDB internamente
    • Funciona na porta padrão 5332 e pode ser acessado diretamente com psql
    • Configurações principais
      • --memory_limit: limite de memória (80% da memória do sistema por padrão)
      • --init_file_path: define o arquivo SQL a ser executado na inicialização
      • --cache_dir: define o diretório de cache para arquivos remotos
  • Configuração de conexão com S3
    • Usa o secrets manager do DuckDB para reconhecer automaticamente credenciais AWS/GCP
    • Exemplo de definição do local de armazenamento de tabelas Iceberg 
      SET pg_lake_iceberg.default_location_prefix TO 's3://testbucketpglake';

Exemplos de uso

  • Criação de tabela Iceberg 
    CREATE TABLE iceberg_test USING iceberg AS   
SELECT i as key, 'val_'|| i as val FROM generate_series(0,99)i;
    • Após a criação, SELECT count(*) FROM iceberg_test; retorna 100
    • Também é possível verificar a localização dos metadados Iceberg
  • COPY com E/S para S3 
    COPY (SELECT * FROM iceberg_test) TO 's3://.../iceberg_test.parquet';  
COPY iceberg_test FROM 's3://.../iceberg_test.parquet';
    • Suporte aos formatos Parquet, CSV e JSON
  • Criar tabela externa a partir de arquivos no S3 
    CREATE FOREIGN TABLE parquet_table()   
SERVER pg_lake   
OPTIONS (path 's3://.../*.parquet');
    • Inferência automática de colunas e possibilidade de consulta (SELECT count(*) FROM parquet_table; → 100)

Arquitetura

  • Componentes
    • PostgreSQL + extensão pg_lake
    • pgduck_server (execução do DuckDB e implementação do protocolo Postgres)
  • Como funciona
    • O usuário se conecta ao Postgres e executa SQL
    • Parte das consultas é executada via DuckDB de forma paralela e orientada a colunas
    • Como o DuckDB não é embutido dentro do processo do Postgres, problemas de segurança de threads e memória são evitados
    • É possível acessar diretamente o mecanismo DuckDB por meio de clientes padrão do Postgres

Lista detalhada de componentes

  • pg_lake_iceberg: implementação da especificação Iceberg
  • pg_lake_table: implementação de FDW para arquivos em armazenamento de objetos
  • pg_lake_copy: suporte a E/S COPY com o data lake
  • pg_lake_engine: módulo comum
  • pg_extension_base: componente base para outras extensões
  • pg_extension_updater: recurso de atualização automática de extensões
  • pg_lake_benchmark: executa benchmarks de tabelas de lake
  • pg_map: gerador de tipo map generalizado
  • pgduck_server: servidor que carrega o DuckDB e o expõe via protocolo Postgres
  • duckdb_pglake: adiciona funções compatíveis com Postgres ao DuckDB

Histórico de desenvolvimento e lançamento

  • No início de 2024, o desenvolvimento começou na Crunchy Data para levar o Iceberg ao Postgres
  • Inicialmente, o foco era a integração com DuckDB e a oferta de recursos para clientes do Crunchy Bridge
  • Depois, foram implementados o protocolo Iceberg v2 e o suporte a transações
  • Em novembro de 2024, foi relançado como Crunchy Data Warehouse
  • Em junho de 2025, a Snowflake adquiriu a Crunchy Data e, em novembro de 2025, o pg_lake foi lançado como open source
    • A versão inicial é a 3.0 (incluindo as duas gerações anteriores)
    • Usuários existentes do Crunchy Data Warehouse recebem um caminho de upgrade automático

Licença e dependências

  • Licença Apache 2.0
  • Depende dos projetos Apache Avro e DuckDB
    • Durante o build, patches são aplicados ao Avro e às extensões do DuckDB

Leituras relacionadas

1 comentários

 
GN⁺ 2025-11-05
Comentários do Hacker News
  • Fico pensando se há algum motivo para simplesmente não usar Ducklake
    Isso permitiria reduzir a complexidade. Tudo que seria necessário é DuckDB e PostgreSQL (pg_duckdb)
    Como referência, também existe o vídeo da apresentação do Prof. Hannes Mühleisen, DuckLake - The SQL-Powered Lakehouse Format for the Rest of Us
    • DuckLake é um projeto bem legal. Nossa equipe também gosta de DuckDB. Na verdade, o pg_lake só foi possível graças ao DuckDB
      O DuckLake consegue fazer coisas que o pg_lake baseado em Iceberg não consegue, e, por outro lado, o Postgres consegue fazer coisas que o DuckDB não consegue. Por exemplo, ele pode lidar com mais de 100 mil inserções de linha única por segundo
      Processamento transacional não sai de graça. Em vez de colocar o engine dentro do catálogo, colocar o catálogo dentro do engine torna possíveis transações entre tabelas analíticas e operacionais
      O Postgres também é natural do ponto de vista de persistência e processamento contínuo. Dá para montar orquestração com pg_cron e PL/pgSQL
      Além disso, o Iceberg também tem como ponto forte a interoperabilidade com vários engines de consulta
    • No fim, é uma questão de decisão de arquitetura. Dá para ver a discussão relacionada neste tópico
    • Eu realmente tentei gostar muito do Ducklake, mas ao usar na prática houve problemas de manutenção. Em especial com o catálogo do pg, às vezes o Ducklake retornava erro HTTP 400 para arquivos que ele mesmo gerava
      Não tenho certeza se isso era por causa do meu padrão de escrita de dados (inserindo de um Polars DataFrame em uma tabela Ducklake) ou da estrutura de tabelas particionadas
      Em ambiente de desenvolvimento/teste foi ok, mas para a equipe inteira houve dificuldades. Então no fim voltei para a combinação de arquivos Parquet particionados em Hive com views no DuckDB
      Penso em abrir uma issue com exemplos depois, mas agora estou sem tempo por causa de outras coisas
  • Isso é realmente uma grande mudança
    Antes eu costumava dizer que não existia um “Snowflake open source” no mercado de Postgres
    A extensão de Postgres da Crunchy é a solução mais avançada do mercado hoje. Parabéns à Snowflake e à equipe da Crunchy por terem aberto isso em open source
    • Sinceramente, acho melhor simplesmente pagar pelo Snowflake e aproveitar esse excelente banco de dados e ecossistema. Se infraestrutura não é o núcleo do valor para o cliente, é melhor delegar essa parte e focar em construir algo incrível
  • Eu gosto de data lakes e de linguagens de consulta parecidas com SQL. Parece uma forma evoluída da filosofia “tudo é arquivo”
    No Linux, é possível ler e escrever configurações do sistema pelo sistema de arquivos (cat /sys/..., echo ... > /sys/...)
    Com FUSE, você pode implementar diretamente um driver de sistema de arquivos no espaço do usuário. Por exemplo, dá para montar SSH ou Google Drive e copiar com o comando cp
    Mas sistemas de arquivos só servem bem para dados hierárquicos. A maior parte dos dados do mundo real tem estrutura relacional
    Data lakes permitem tratar diferentes fontes de dados como se fossem um único banco de dados relacional por meio da abstração elegante do SQL
    No fim, como muitas aplicações são centradas em CRUD, essa abordagem é muito mais eficiente
  • Como você usa um data lake? Para mim, ele não é só armazenamento, mas um espaço para tarefas analíticas imprevisíveis
    Nesses casos, o Postgres tem limites. Você precisa de mais CPU e RAM e, no fim, de um engine distribuído
    • A essência de um data lake é a separação entre computação e armazenamento. O Postgres não é a camada de computação, e sim a camada de acesso
      A computação pergunta ao Postgres “qual é o dado atual destas chaves?” ou “qual era o dado de duas semanas atrás?”, e as consultas analíticas de fato são executadas diretamente nos arquivos Parquet
  • Quando a Snowflake adquiriu a Crunchy Data, eu esperava que oferecessem uma versão gerenciada assim
    É ótimo poder rodar localmente com Docker, mas seria bom poder operar isso na AWS com cobrança integrada à conta da Snowflake
  • Parece mesmo que agora é a era de ouro do PostgreSQL
  • Não sou engenheiro de dados, mas trabalho em uma área relacionada. Queria saber se alguém consegue explicar de forma simples que problema isso resolve
    • Por exemplo, imagine um serviço que acumula dados de logs em arquivos Parquet no S3. Se você quiser consultar esses dados diretamente do Postgres, o pg_lake é útil
      Você pode trazer os dados Parquet para o Postgres e consultá-los, além de fazer joins com tabelas existentes
  • Tenho duas perguntas
    (1) Há algum plano de compatibilidade para usar a especificação Ducklake em vez de Iceberg? O Ducklake gerencia o catálogo em tabelas SQL, não em arquivos, o que simplifica escrita concorrente e gerenciamento de snapshots
    (2) Existe a possibilidade de o pg_duckdb acabar oferecendo a mesma funcionalidade com o tempo?
    • (1) Nós consideramos isso, mas no momento não há plano. Em vez de usar Ducklake diretamente, queremos implementar isso dentro do Postgres para manter os limites transacionais
      Ainda assim, há complexidades, como o processamento de dados inline. Se resolvermos isso, podemos obter alto desempenho transacional
      (2) Para o pg_duckdb é mais fácil reutilizar a implementação do Ducklake, mas achamos que essa estrutura é menos adequada em termos de gerenciamento de recursos e estabilidade
  • Entre S3 Table Buckets, Cloudflare R2 Data Catalog e este projeto, parece que o Iceberg está vencendo
  • Se você quer carregar dados facilmente em um banco compatível com Postgres Wire, recomendo sling-cli
    Dá para executar tarefas de ETL via CLI, YAML e Python