Nos últimos anos trabalhando com engenharia de dados e plataformas de processamento distribuído, uma das coisas que mais me chamou a atenção foi como o SQL deixou de ser apenas uma linguagem de consulta para bancos relacionais e passou a se adaptar a ambientes massivamente paralelos, orientados a arquivos e altamente elásticos — como o Databricks.

Sim, o SQL é “padrão”… até você tentar rodar uma query do PostgreSQL no Databricks e perceber que ela quebra de formas inesperadas. Eu já passei por isso inúmeras vezes. E foi justamente dessa dor (e aprendizado) que resolvi escrever este artigo: um guia detalhado, objetivo e direto ao ponto sobre como o SQL tradicional difere do SQL aplicado ao Databricks.

O objetivo é que você termine este texto sabendo exatamente o que muda, por que muda e como escrever queries de forma eficiente em um Lakehouse.

1. Antes de tudo: Databricks não é um banco de dados — é um Lakehouse

No começo, eu tentei usar Databricks como se fosse um PostgreSQL "turbão". Grave erro.

O Databricks tem uma camada SQL poderosa, mas por baixo dele existem:

• Arquivos em armazenamento distribuído (Parquet, Delta)

• Motor de execução Spark

• Catálogo unificado

• Controle transacional Delta Lake

Ou seja: as queries são SQL, mas a execução não tem nada a ver com um banco tradicional.

Isso impacta diretamente:

• sintaxe

• funções

• performance

• modelagem

• otimização

• governança

2. Dialeto SQL: ANSI SQL vs Databricks SQL

O Databricks SQL segue o padrão ANSI SQL, mas adiciona extensões próprias — principalmente herdadas do Apache Spark — e altera alguns comportamentos clássicos do SQL tradicional.

Aqui vai uma visão geral do “DNA” de cada lado:

3. As principais diferenças práticas que eu encontro no dia a dia

3.1. Manipulação de dados semiestruturados: Databricks dá um show

No SQL tradicional, JSON é dor de cabeça: funções específicas, parsing manual, baixa performance.

No Databricks?

A primeira vez que escrevi algo assim, eu entendi que Databricks trata JSON como se fosse coluna nativa.

Tipos como:

• MAP<STRING, STRING>

• ARRAY<STRING>

• STRUCT<...>

são comuns — e extremamente úteis.

3.2. Criação e gerenciamento de tabelas: Delta Lake muda tudo

Em PostgreSQL:

No Databricks:

Ou seja, você escolhe o formato da tabela (Delta, Parquet, CSV…).

Além disso, o SQL do Databricks tem comandos exclusivos para trabalhar com Delta Lake, que simplesmente não existem no SQL tradicional:

Se você vier do mundo SQL clássico, isso parece magia.

3.3. MERGE INTO: a queridinha do Lakehouse

PostgreSQL tem UPSERT, MySQL tem sua própria sintaxe, Oracle outra… No Databricks, o MERGE é amplamente utilizado:

E com performance absurda porque opera sobre arquivos Delta.

3.4. Funções diferentes (e mais poderosas) no Databricks SQL

Muita coisa funciona igual. Mas muita coisa é exclusiva.

Exemplos que não existem no SQL tradicional:

• explode() – explode arrays

• inline() – transforma arrays de structs em linhas

• from_json() / to_json()

• map_keys() / map_values()

• transform() / reduce() (funções funcionais dentro do SQL)

• element_at()

Exemplo real:

SELECT explode(items) as item FROM pedidos;
 

Isso simplesmente não existe em bancos SQL tradicionais.

3.5. Window functions mais flexíveis

Ambos suportam funções de janela, mas o Databricks tende a aceitar padrões mais flexíveis e menos restrições, justamente por operar em um mecanismo distribuído.

3.6. Cuidado: alguns comportamentos clássicos mudam

Exemplos:

• COUNT(NULL) no Spark retorna 0, enquanto alguns bancos retornariam comportamento diferente.

• Ordenação sem ORDER BY em ambiente distribuído é não determinística (óbvio depois que você aprende… mas eu apanhei para perceber).

• DISTINCT em arrays funciona de forma totalmente diferente.

4. Performance: index vs Z-Order vs Partition

Quem vem do mundo relacional está acostumado com:

• índices

• índices compostos

• índices B-Tree, Hash, GIN

No Databricks, o raciocínio é outro.

No Lakehouse, o que manda é:

• partição de arquivos

• organização de dados (Z-Order)

• tamanho de arquivos (auto-optimize)

• caching

• broadcast joins

Exemplo:

Esse comando fisicamente reorganiza os arquivos para acelerar leitura — algo que simplesmente não existe no SQL tradicional.

5. Governança: Databricks SQL + Unity Catalog

Enquanto um banco tradicional controla permissões dentro do próprio SGBD, no Databricks eu passo por algo mais moderno:

• Catalog → Schema → Table

• Controle por Identidades (IAM)

• Lineage automático

• Auditar operações via Delta Log

E isso muda a forma como eu penso no “banco”.

6. Conclusão: O SQL do Databricks é SQL… mas é um SQL para o futuro

Depois de anos trabalhando com bancos relacionais, percebi que usar Databricks exigiu um “reset mental” em algumas partes:

• esqueci índices

• abracei arquivos

• aprendi a otimizar storage

• passei a tratar JSON como primeira classe

• entendi que SQL pode ser distribuído, elástico e transacional — tudo ao mesmo tempo

Hoje, quando escrevo SQL para Databricks, sinto que estou lidando com uma evolução natural do SQL tradicional, adaptada para o mundo dos dados massivos.

Se você trabalha ou quer trabalhar com engenharia de dados moderna, arquitetura Lakehouse e pipelines de larga escala, dominar essas diferenças não é opcional — é obrigatório.

E quanto mais rápido você entender isso, mais cedo vai aproveitar todo o poder do Databricks.