Lakebase é o banco PostgreSQL serverless do Databricks. É um banco OLTP totalmente gerenciado, integrado à plataforma Databricks, que roda sobre a arquitetura adquirida do Neon em maio de 2025 por $1 bilhão.
Ficou em General Availability no AWS em fevereiro de 2026. Azure entrou em GA em seguida, e GCP está previsto para mais adiante no mesmo ano.
Origem e motivação
O Databricks sempre foi forte em OLAP: queries analíticas, ML, pipelines batch. O que faltava era um banco transacional para fechar o ciclo: agentes de IA, aplicações web, sistemas que precisam de leitura/escrita de baixa latência junto dos dados do lakehouse.
A aquisição do Neon resolveu isso. O Neon já tinha resolvido os problemas mais difíceis de rodar Postgres na nuvem em escala: separar compute de storage, branching instantâneo, autoscaling real.
Arquitetura
O Lakebase herda a arquitetura do Neon e divide o banco em duas camadas independentes:
AS``` ┌──────────────────────────────────────────────────────┐ │ LAKEBASE ARCHITECTURE │ │ │ │ ┌─────────────────────────────────────────────┐ │ │ │ Compute Layer │ │ │ │ PostgreSQL 16 / 17 (standard engine) │ │ │ │ Autoscaling · 52 extensões · pgvector │ │ │ └────────────────────┬────────────────────────┘ │ │ │ WAL stream │ │ ┌─────────────────────▼──────────────────────┐ │ │ │ Storage Layer │ │ │ │ Copy-on-write · Branching · Point-in-time │ │ │ │ Até 8 TB por instância · Object storage │ │ │ └────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────┘
**Compute layer**: roda o PostgreSQL padrão (versão 16 ou 17). Escala independentemente do storage, podendo ir a zero quando inativo.
**Storage layer**: recebe o stream de WAL (Write-Ahead Log) do compute e persiste as páginas com copy-on-write. É nesse layer que vive o branching.
Essa separação entrega 5x mais velocidade em writes comparado ao Postgres tradicional, porque o storage layer processa WAL de forma assíncrona e paralela.
## Features principais
### Branching instantâneo
Criar um branch é uma operação no nível de ponteiros de storage, não uma cópia de dados. Um banco de 1 TB ganha um branch em segundos, e as páginas só divergem quando escritas (copy-on-write).
Casos de uso diretos:
- Testar uma migration sem afetar produção
- Dar a cada desenvolvedor um ambiente isolado com dados reais
- CI/CD: criar um branch por PR, destruir ao mergear
### Integração com Unity Catalog
O Lakebase sincroniza tabelas do Unity Catalog diretamente para o banco Postgres. Dados analíticos do lakehouse ficam disponíveis para queries transacionais com latência baixa, sem ETL separado e sem duplicar dados.
Isso fecha o ciclo: dados gerados por pipelines batch ou streaming no Databricks podem ser consumidos por aplicações conectadas ao Lakebase via JDBC/PSQL padrão.
### pgvector e extensões
O Lakebase suporta 52 extensões, incluindo:
| Extensão | Uso |
|---|---|
| `pgvector` | busca vetorial para AI (embeddings, similarity search) |
| `PostGIS` | dados geoespaciais |
| `pg_stat_statements` | análise de performance de queries |
| `PL/pgSQL` | stored procedures |
### Autoscaling e scale-to-zero
O compute escala automaticamente conforme a carga. Quando não há conexões ativas, escala a zero e para de cobrar. Isso torna o Lakebase adequado para workloads intermitentes, como agentes de IA que escrevem estado apenas durante execuções.
### Point-in-time recovery
Recupera o estado do banco para qualquer milissegundo dentro da janela de retenção configurada. Útil para reverter bugs em aplicação ou deleções acidentais.
## Casos de uso
**Agentes de IA**: armazenar estado, memória e histórico de execuções de agentes diretamente dentro da plataforma Databricks.
**Aplicações web transacionais**: CRUD de baixa latência usando Postgres padrão, com os dados acessíveis também via Spark para analytics.
**Desenvolvimento e testes**: branches por ambiente eliminam a necessidade de bancos separados para dev, staging e QA.
**OLTP + OLAP unificados**: uma aplicação grava no Lakebase, os dados ficam sincronizados com Unity Catalog e disponíveis para notebooks, jobs e SQL Warehouses sem ETL.
## Compatibilidade PostgreSQL
O Lakebase é PostgreSQL padrão. Qualquer driver, ORM ou ferramenta que conecta via protocolo Postgres funciona sem alteração. Para quem vem do SQL Server, o ponto de entrada é o mesmo protocolo, mas com as funções e sintaxe do Postgres.
Ver [[postgres-funcoes-equivalentes-sqlserver]] para o guia de funções equivalentes entre SQL Server e PostgreSQL.
## Disponibilidade
| Cloud | Status (maio 2026) |
|---|---|
| AWS | GA |
| Azure | GA |
| GCP | Previsto para 2026 |
Desde março de 2026, novas instâncias são criadas como Autoscaling projects. Instâncias Provisioned existentes serão migradas automaticamente a partir de junho de 2026.
## Conexões
- [[databricks-lakebase-conexao]] - Criação de usuários, service principals, permissões e conexão de aplicações
- [[databricks]] - Visão geral da plataforma Databricks
- [[databricks-unity-catalog]] - Unity Catalog e governança
- [[databricks-jobs]] - Jobs e pipelines que alimentam o Lakebase
- [[postgres-funcoes-equivalentes-sqlserver]] - Guia de funções PostgreSQL para quem vem do SQL Server
- [[gcp-alloydb]] - AlloyDB, alternativa PostgreSQL gerenciada do GCP
- [[gcp-cloud-sql]] - Cloud SQL com PostgreSQL no GCP
- [[data-lake-lakehouse]] - Conceito de Lakehouse que o Lakebase estende para OLTP
## Referências
- [Databricks Lakebase is now Generally Available](https://www.databricks.com/blog/databricks-lakebase-generally-available)
- [A New Era of Databases: Lakebase](https://www.databricks.com/blog/what-is-a-lakebase)
- [How Lakebase Architecture Delivers 5x Faster Postgres Writes](https://www.databricks.com/blog/how-lakebase-architecture-delivers-5x-faster-postgres-writes)
- [Lakebase Postgres (AWS Docs)](https://docs.databricks.com/aws/en/oltp/)
- [Databricks Introduces Lakebase (InfoQ)](https://www.infoq.com/news/2026/02/databricks-lakebase-postgresql/)