O que é a arquitetura LTAP
Em junho de 2026, o Databricks publicou detalhes sobre o Lakebase e a arquitetura LTAP (Log-structured Tiered Access Protocol), que separa o armazenamento do banco de dados em camadas: dados quentes em memoria e disco local, dados mornos em armazenamento barato como S3, e dados frios em Parquet diretamente no object storage.
A ideia central e simples: não faz sentido manter todos os dados do Postgres em disco local caro quando a maioria das consultas acessa apenas uma fração pequena dos dados. Dados antigos raramente consultados podem ficar em S3 em formato Parquet, muito mais barato, e serem carregados sob demanda quando necessário.
Isso não e conceito novo - bancos de dados como Aurora e Snowflake já separam computação de armazenamento. O que o LTAP traz de novo e a abordagem para dados Postgres especificamente, mantendo compatibilidade total com o protocolo wire do Postgres enquanto tira dados para S3.
Como funciona por baixo dos panos
A arquitetura LTAP organiza os dados em três níveis de acesso. O nível quente fica em memoria RAM e disco NVMe local - e onde vivem os dados mais acessados recentemente. O nível morno fica em disco de bloco mais barato ou em S3 com cache local. O nível frio fica em Parquet diretamente no S3, sem cache.
O banco de dados mantem metadados sobre onde cada tabela ou partição de tabela esta armazenada. Quando uma query acessa dados frios no S3, o sistema faz o download do Parquet, converte para o formato interno, executa a query, e descarta o dado local se a memoria estiver cheia. Esse processo e transparente para a aplicação - ela ve apenas Postgres.
O formato Parquet e perfeito para dados frios porque e colunar, comprimido e suporta predicado pushdown. Isso significa que ao buscar dados antigos no S3, o sistema não precisa baixar a coluna inteira - pode filtrar no nível do Parquet antes do download.
O conceito de separar computação de armazenamento e chamado de disaggregated storage. Bancos como o Néon, PlanetScale e CockroachDB já adotam variantes dessa abordagem para escalar de forma mais económica.
Principais benefícios
A arquitetura LTAP resolve problemas reais de custo e escala:
- Redução de custo de armazenamento: S3 custa cerca de 23 dólares por TB/mes, enquanto disco SSD gerenciado pode custar 10x mais. Para dados frios, a economia e enorme
- Escalabilidade independente: você pode aumentar o armazenamento sem precisar de instâncias maiores ou mais replicas
- Compatibilidade com o ecossistema: qualquer ferramenta que fala Postgres continua funcionando sem modificações
- Dados históricos acessíveis: em vez de arquivar dados antigos e perder a capacidade de query, eles ficam disponíveis via SQL normal
- Integração com data lake: o mesmo Parquet no S3 pode ser lido por Spark, Athena, Trino e outras ferramentas de analytics sem ETL adicional
Como começar: ferramentas que implementam essa abordagem
O Lakebase do Databricks ainda não esta disponível para todos. Mas existem alternativas que implementam conceitos similares já hoje:
# Néon - Postgres serverless com armazenamento separado
# Crie um projeto em néon.tech e conecte como Postgres normal
psql PostgreSQL://usuário:[email protected]éon.tech/neondb
# pg_lakehouse - extensão open source que lê Parquet do S3 via DuckDB
CREATE EXTENSION pg_lakehouse;
CREATE FOREIGN TABLE vendas_historico
USING parquet OPTIONS (path 's3://meu-bucket/vendas/', region 'us-east-1');
SELECT * FROM vendas_historico WHERE ano = 2023;Para quem quer experimentar a ideia com ferramentas existentes, o pg_lakehouse (do projeto ParadeDB) permite criar tabelas externas que apontam para Parquet no S3. Não e exatamente LTAP, mas da a ideia de como queries em dados frios no S3 via Postgres funcionam.
Latência de acesso a dados frios no S3 e muito maior do que dados locais. A arquitetura LTAP funciona bem quando queries em dados frios são raras ou tolerantes a latência mais alta. Para workloads OLTP puro, dados frios no S3 podem ser um gargalo.
Exemplo prático
Imagine um SaaS com tabela de logs de acesso. Você tem 5 anos de dados, mas queries de produção acessam apenas os últimos 30 dias. Com LTAP:
-- Dados dos últimos 30 dias: NVMe local, query rápida
SELECT COUNT(*) FROM logs WHERE criado_em > NOW() - INTERVAL '30 days';
-- Resultado em ~10ms
-- Dados de 2 anos atrás: S3 Parquet, mais lento mas funciona
SELECT COUNT(*) FROM logs WHERE criado_em BETWEEN '2024-01-01' AND '2024-12-31';
-- Resultado em ~2s (download do Parquet + query)
-- A aplicação não sabe a diferença - e Postgres para elaO sistema gerência automaticamente quais dados estão em que camada. Dados recentemente acessados sobem para camadas mais rápidas. Dados não acessados por tempo configurable descem para Parquet no S3.
Comparação com alternativas
O Amazon Aurora já separa computação de armazenamento, com dados em storage distribuído próprio da AWS. E mais maduro que LTAP mas lock-in total na AWS e mais caro que S3.
O Snowflake e o BigQuery também armazenam dados em object storage, mas são bancos OLAP, não OLTP. Não substituem Postgres para aplicações transacionais.
O Néon e o Supabase oferecem Postgres com separação de armazenamento, mas com arquiteturas próprias. O LTAP/Lakebase promete fazer isso de forma mais integrada com o ecossistema de data lake.
O DuckDB consegue ler Parquet diretamente no S3 com performance excelente para queries analíticas. Para workloads de relatório em dados históricos, usar DuckDB apontando para Parquet no S3 pode ser mais simples e barato do que manter tudo no Postgres.
Pontos positivos e limitações
Pontos positivos: custo de armazenamento muito menor para dados frios, compatibilidade total com Postgres, integração natural com ecossistema de data lake, escala de armazenamento independente de computação.
Limitações reais: latência maior para dados frios, complexidade operacional adicional, tecnologia ainda emergente (Lakebase não esta em GA para todos). Workloads que acessam dados de qualquer época com alta frequência não se beneficiam tanto.
Também é preciso pensar em backups e durabilidade. Dados em S3 tem durabilidade elevada, mas a consistência entre o que esta no Postgres e o que esta no Parquet e um ponto crítico que cada implementação resolve de forma diferente.
Casos de uso reais
SaaS com dados históricos: plataformas de analytics, CRMs e ERPs que acumulam anos de dados mas queries de produção acessam apenas o recente. Ideal para reduzir custo sem perder a capacidade de query histórica.
IoT e telemetria: series temporais de sensores onde dados novos chegam constantemente mas dados antigos raramente são consultados. A separação por camadas faz todo sentido economicamente.
Compliance e auditoria: dados que precisam ser mantidos por anos por regulamentação, mas quase nunca consultados. Manter em S3 Parquet e muito mais barato do que em disco gerenciado.
Startups em crescimento: que começam pequenas mas sabem que vao acumular grande volume de dados. Planejar a arquitetura com separação de armazenamento desde cedo evita migração dolorosa no futuro.
Dicas e boas práticas
Para que a tiering funcione bem, as tabelas precisam ser particionadas por data ou por outro campo natural. Sem partições, o sistema não consegue mover dados frios para S3 sem varrer a tabela inteira.
Mantenha métricas de quantos dados estão em cada camada e quais queries estão acessando dados frios. Se muitas queries de produção estão batendo em S3, talvez o critério de tiering precise de ajuste.
Transações que envolvem dados em camadas diferentes (quentes e frios ao mesmo tempo) podem ter implicações de performance e isolamento. Planeje o schema para minimizar operações que cruzam camadas.
Vale a pena adotar?
Para quem tem grandes volumes de dados históricos e quer reduzir custo sem abrir mao da capacidade de query via SQL, a arquitetura de tiered storage e um caminho claro. A questão hoje e escolher entre solu coes maduras como Aurora ou experimentar alternativas mais novas como Néon ou aguardar o Lakebase do Databricks.
A tendência e clara: separação de computação e armazenamento vai se tornar padrão em bancos de dados, assim como já e em data warehouses. Quanto antes você entender os tradeoffs, mais preparado estará para as próximas decisões de arquitetura.
O próximo passo prático: explore o pg_lakehouse ou crie um projeto no Néon para experimentar a ideia com seu caso de uso. Ver na prática como a latência de dados frios se comporta no seu workload específico vai te dar muito mais contexto do que qualquer benchmark genérico.