Você pode reduzir o custo do Databricks Serverless SQL Warehouse associando cada problema de workload ao controle certo. O auto-stop reduz o tempo ativo sem uso, o tamanho do warehouse afeta o desempenho de queries individuais e o max clusters controla quanta concorrência o warehouse consegue absorver.
O desafio é que esses sinais costumam se misturar. Um warehouse que permanece ativo entre jobs curtos não precisa de mais potência. Workloads esperando por capacidade podem precisar de mais clusters, e não de um warehouse maior. O DirectQuery do Power BI também pode continuar gerando atividade no Databricks SQL mesmo quando o SQL em si já está bem otimizado.
Este artigo mostra como diferenciar esses casos, comparar o Serverless com o Pro e o Classic usando o custo total em vez de apenas o preço por DBU, e escolher a configuração que corresponde ao comportamento que você está observando de fato. Essas decisões no nível do warehouse fazem parte do framework completo de otimização de custos do Databricks, em que dimensionamento, utilização, atribuição e automação trabalham juntos.
TL;DR
- O auto-stop reduz as janelas de ociosidade entre picos de trabalho SQL.
- O tamanho do warehouse controla a capacidade de computação disponível para queries individuais.
- O max clusters controla quanta demanda simultânea o warehouse consegue atender.
- Serverless, Pro e Classic precisam ser comparados pelo custo total do workload, não apenas pelo preço por DBU.
- O modo de conexão do Power BI pode mudar significativamente a atividade do SQL Warehouse quando o
DirectQueryé usado para um nível de atualização de que o negócio não precisa.
Por que inicializações e tempo ocioso elevam o custo do Databricks SQL Warehouse
Sua fatura do SQL Warehouse pode crescer mais rápido do que o tempo de execução das queries sugere, porque jobs curtos ainda geram inicializações e janelas ativas. Alertas agendados fazem o problema passar despercebido com facilidade: várias queries de menos de um minuto em agendamentos separados podem manter um Databricks Serverless SQL Warehouse ativo por muito mais tempo do que o SQL em si leva para rodar. A configuração pode piorar essa diferença. Um deployment de bundle documentado omitiu auto_stop_mins e acabou com um valor de 120 minutos, embora a documentação atual dos Databricks Declarative Automation Bundles liste um padrão de 10 minutos para Serverless.
Nossa leitura é que um erro de configuração oculto pode causar mais estragos do que uma única query lenta, porque ele se repete a cada execução. Quanto da sua fatura do SQL Warehouse vem de queries caras, e quanto vem de configurações que ninguém revisitou? O mesmo padrão aparece nos cinco hábitos que impactam a fatura do Databricks e no framework completo de otimização de custos.
Tipos de SQL warehouse do Databricks: Serverless vs. Pro vs. Classic
Entre os principais tipos de SQL warehouse, o Serverless tem a taxa visível de Databricks Unit (DBU) mais alta porque seu preço já inclui a infraestrutura subjacente. Um Pro SQL warehouse tem uma taxa de DBU menor, e o Classic, a menor de todas, mas ambos cobram a infraestrutura de nuvem separadamente. Com a computação serverless, o Databricks gerencia a infraestrutura subjacente em vez de expor uma cobrança separada de infraestrutura de nuvem para você administrar.
Por exemplo, as tarifas de lista AWS Premium publicadas em US East colocam o Serverless em cerca de $0,70 por DBU, um Pro SQL warehouse em $0,55 e o Classic em $0,22, com dados de 2026. As tarifas reais podem variar por nuvem, região, edição e contrato. Esses números se referem a um único exemplo de precificação regional, mas mostram por que a taxa de DBU sozinha não diz qual opção custa menos no total.
| Tipo | Taxa de DBU relativa | Cobrança de infraestrutura | Cold start | Melhor uso |
|---|---|---|---|---|
| Serverless | Mais alta | Incluída | Normalmente segundos | Workloads intermitentes e interativos de BI e DirectQuery |
| Pro | Intermediária | Cobrada separadamente | Normalmente minutos | Workloads de BI previsíveis que precisam dos recursos do Pro |
| Classic | Mais baixa | Cobrada separadamente | Normalmente minutos | Workloads agendados previsíveis |
Serverless SQL warehouses são mais adequados para demanda intermitente porque conseguem iniciar em segundos e responder rapidamente conforme a demanda muda. O Databricks SQL Serverless também usa o Intelligent Workload Management (IWM) para prever as necessidades de recursos das queries e gerenciar a capacidade conforme a demanda varia. Isso reduz a necessidade de manter a computação aquecida só para evitar uma longa demora na inicialização.
Pro SQL warehouses e Classic SQL warehouses são mais relevantes quando a demanda é previsível. O Databricks recomenda esses SQL warehouses para jobs agendados de Import ou Extract, em que a demanda é mais fácil de planejar e a inicialização rápida importa menos. Um Pro SQL warehouse adiciona recursos além do Classic SQL, que continua sendo a opção de menor DBU para casos de uso mais simples.
A comparação que vale é o custo total de executar o workload, incluindo infraestrutura, comportamento de inicialização e por quanto tempo o warehouse precisa permanecer ativo. Olhar apenas para a taxa de DBU leva ao mesmo erro de enxergar só metade da fatura e pode fazer o Serverless parecer mais caro do que realmente é.
Se você quer comparar esses custos no nível do warehouse, o SELECT for Databricks pode ajudar a visualizar de onde vêm os gastos, o dimensionamento e a utilização do SQL Warehouse antes de mudar a configuração.
Auto-stop do SQL warehouse: os mínimos da UI e da API são diferentes
Serverless SQL warehouses dão mais margem para encurtar o auto-stop do que os Pro ou Classic SQL warehouses. Na UI do Databricks, o mínimo para Serverless é de cinco minutos, enquanto a API e os Declarative Automation Bundles permitem reduzir auto_stop_mins para um minuto. Pro e Classic têm um mínimo de 10 minutos.
A configuração mais curta nem sempre é a certa. Um auto-stop de um minuto pode servir para jobs agendados isolados, enquanto workloads interativos de DirectQuery podem se beneficiar de permanecer aquecidos por mais tempo. Nossa orientação sobre auto-stop de SQL Warehouse recomenda cerca de 10 minutos para uso geral de SQL.
Você pode configurar um warehouse Serverless com auto-stop de um minuto usando a CLI do Databricks:
databricks warehouses edit <WAREHOUSE_ID> \ --auto-stop-mins 1Os padrões também dependem de como você cria os SQL warehouses. A UI do Databricks usa como padrão 10 minutos para Serverless e 45 minutos para Pro ou Classic, enquanto os Declarative Automation Bundles usam 10 minutos para Serverless e 120 minutos para Pro ou Classic. Defina auto_stop_mins explicitamente para que o deployment não dependa do padrão desse caminho de configuração.
Dimensionando um SQL warehouse: tamanho vs. clusters
No Databricks SQL, o tamanho do warehouse e o max clusters resolvem problemas de desempenho diferentes. O tamanho controla a computação disponível para queries individuais, enquanto o max clusters controla quanta demanda simultânea o warehouse consegue atender. O Serverless também usa o Intelligent Workload Management para cuidar automaticamente de parte da alocação de recursos.
Use os sinais de query e de fila para decidir qual controle ajustar:
| Sintoma | Controle a ajustar |
|---|---|
| Uma única query está lenta ou faz spill intenso para o disco | Aumente o tamanho do warehouse |
| As queries passam muito tempo esperando no limite de capacidade | Aumente o max clusters |
| O Peak Queued Queries permanece acima de zero | Verifique tanto o tamanho do warehouse quanto o max clusters |
| Longos intervalos ociosos entre queries | Reduza o auto-stop |
O Peak Queued Queries sozinho não identifica a correção exata. Um waiting_at_capacity_duration_ms alto aponta para pressão de capacidade, enquanto queries lentas ou com muito spill apontam mais para o tamanho do warehouse. Nossa preferência é confirmar se a pressão está no nível da query ou da concorrência antes de adicionar mais computação.
O tempo ocioso indica um problema diferente. Quando a capacidade é suficiente durante a execução das queries, mas o warehouse permanece ativo entre os jobs, o auto-stop é a configuração a inspecionar.
Quando o DirectQuery do Power BI muda a equação de custo do serverless
O DirectQuery do Power BI pode gerar muito mais atividade no warehouse do que o dashboard em si parece justificar, porque cada interação pode enviar mais uma query ao Databricks. O Databricks recomenda Serverless SQL Warehouses para DirectQuery e LiveQuery, com uma janela de auto-stop de 15 a 30 minutos para workloads interativos.
Quando o negócio só precisa de atualizações a cada poucos minutos, modelos Import ou Hybrid podem reduzir a atividade do Databricks SQL atendendo mais interações de relatório a partir do próprio Power BI. Views materializadas também podem pré-computar trabalho SQL repetido, embora suas atualizações ainda usem computação serverless separada.
Nossa visão é que o DirectQuery deve ser um dos primeiros pontos a investigar quando o custo do Serverless parece desconectado da complexidade do dashboard. Antes de culpar a precificação do Serverless, verifique se o modo de conexão do BI está gerando mais atividade do que o requisito de atualização dos dados realmente exige.
Transformando esses ajustes em rotina
Manter o custo do SQL Warehouse sob controle exige visibilidade contínua de dimensionamento, tempo ocioso e pressão de capacidade. Nossa visão de custos do SQL Warehouse reúne esses sinais para que você veja onde a configuração merece uma nova olhada.
Nosso Automated Savings pode ajustar configurações compatíveis de contagem de workers e autoscaling dos SQL Warehouses conforme a demanda muda. O auto-stop continua sendo um controle separado, então você ainda deve revisar auto_stop_mins após os deployments e auditar os modos de conexão do BI quando a atividade deixar de corresponder ao requisito de atualização do negócio.
O próximo nível de economia é transformar essas verificações em um hábito operacional. A decisão é se revisar manualmente tamanho, max clusters, auto-stop e modos de BI ainda é um custo-benefício que se justifica, ou se esse trabalho recorrente está começando a se acumular.
Custo do Databricks Serverless SQL Warehouse: o que ajustar primeiro
Associe a configuração ao sinal que você está vendo: janelas ociosas apontam para o auto-stop, pressão de fila para a capacidade, queries individuais lentas para o tamanho do warehouse e atividade de BI inesperada para o modo de conexão. Compare Serverless, Pro e Classic pelo custo total, e não apenas pelo preço por DBU.
Revise as evidências antes de mudar a configuração. Nossa visão de custos do Databricks reúne custo do SQL Warehouse, dimensionamento, computação ociosa e utilização para que você veja qual configuração merece atenção primeiro.