O Databricks cobra o processamento em Databricks Units (DBUs), faturadas por segundo, em cima de uma conta separada do seu provedor de nuvem por máquinas virtuais, armazenamento e egress. O custo total depende do tipo de workload (Jobs vs. All-Purpose vs. SQL), do plano (Standard, Premium ou Enterprise) e da plataforma de nuvem. Times que rodam workloads de produção em batch em clusters All-Purpose, em vez de Jobs, costumam pagar de 3 a 4 vezes mais do que o necessário. O caminho para um gasto previsível com Databricks passa por disciplina no tipo de workload, políticas de auto-termination, governança de cluster e monitoramento contínuo de custos.
A maioria dos times de CloudOps e FinOps chega ao Databricks esperando uma conta de nuvem direta. Recebe duas. O Databricks cobra o processamento na sua própria moeda, as DBUs, enquanto o provedor de nuvem fatura à parte as máquinas virtuais, o armazenamento e o egress que sustentam esses workloads. Nenhuma das contas conhece a outra.
E essa estrutura dupla não é a única complexidade. As taxas de consumo de DBU variam por um fator de 3 a 4, dependendo de o workload rodar como um job agendado ou em um notebook interativo. Os planos multiplicam de novo a tarifa por DBU. Some a isso transferência de dados entre regiões e cobranças de clusters ociosos, e um time com workloads perfeitamente razoáveis pode ver contas mensais 50% a 200% acima da previsão inicial.
Este guia destrincha cada componente de custo, mostra onde os times gastam demais e apresenta as práticas de monitoramento e governança que transformam o Databricks de incógnita financeira em uma capacidade operacional previsível.
O que é o preço do Databricks e como funcionam os planos?
O preço do Databricks segue um modelo de consumo pay-as-you-go, construído em torno das Databricks Units (DBUs). Uma DBU representa uma medida normalizada de capacidade de processamento, faturada com granularidade por segundo. A tarifa de DBU é multiplicada pelo número de unidades que um workload consome, e esse resultado vira o seu custo de software Databricks. O provedor de nuvem fatura à parte a infraestrutura por baixo.
Hoje, a plataforma oferece três planos na AWS: Standard, Premium e Enterprise. No Azure e no GCP, Standard e Premium continuam disponíveis, mas a Microsoft já anunciou a desativação do plano Standard no Azure para outubro de 2026. Novos clientes AWS e GCP agora começam direto no Premium como plano base. Cada upgrade entrega mais recursos de governança, segurança e otimização — e eleva a tarifa por DBU na mesma proporção.
Standard, Premium e Enterprise: o que cada plano inclui?
O Standard cobre engenharia de dados básica e notebooks colaborativos. Não inclui Databricks SQL Workspace nem ferramentas de otimização SQL. O Premium adiciona Unity Catalog para governança de dados, controles de acesso baseados em função, recursos de análise SQL e os recursos de auditoria e compliance que a maioria dos times enterprise exige. O Enterprise acrescenta suporte dedicado, ferramentas avançadas de ciclo de vida de ML e preços negociados para consumo comprometido.
A escolha do plano importa por dois motivos: aderência de capacidade e baseline de custo. Um time que roda exclusivamente ETL automatizado pode ficar no Standard. Um time que precisa de análise SQL para profissionais de BI, governança em múltiplos workspaces ou rastreamento de linhagem de dados precisa do Premium. A maior parte das organizações de médio porte fica no Premium e deve construir seus modelos de custo baseline em cima dessas tarifas.
Preço por consumo vs. descontos por uso comprometido
O preço on-demand não exige compromisso prévio e funciona bem para times que ainda estão mapeando seus padrões de workload. Contratos de uso comprometido (chamados de Databricks Commit Units, ou DBCUs, no Azure) oferecem descontos relevantes em troca de garantias de consumo de 1 ou 3 anos. O Azure anuncia economia de até 37% para um compromisso DBCU de 3 anos. AWS e GCP oferecem estruturas comparáveis pelos seus respectivos acordos de marketplace.
O critério prático para se comprometer é simples: se o seu time roda workloads consistentes e previsíveis e tem pelo menos 6 meses de histórico de uso para ancorar a previsão, os commitments compensam. Se os workloads ainda estão evoluindo ou são sazonais, o on-demand preserva flexibilidade pagando um prêmio. O Databricks oferece uma calculadora de preços para cada provedor de nuvem, útil para modelar o consumo de DBU antes de fechar o compromisso.
Quanto custa o Databricks na prática? Um detalhamento completo de DBU
Orçar Databricks sem entender os tipos de workload é o caminho mais comum para o susto na fatura. O tipo de processamento que sustenta um workload determina a tarifa de DBU, e a diferença é grande o suficiente para pesar em toda fatura mensal.
Preço de DBU por tipo de workload
O Jobs Compute roda workloads agendados e automatizados: pipelines ETL, checagens de qualidade de dados, agregações em batch. Os clusters sobem quando o job começa e são desligados quando ele termina. É a categoria de processamento mais barata. Já o All-Purpose Compute dá suporte a trabalho interativo em notebooks compartilhados, análise exploratória e desenvolvimento. Esses clusters ficam rodando até alguém parar. O prêmio do interativo reflete uma exposição real ao tempo ocioso: um cluster All-Purpose deixado ligado durante a noite por um cientista de dados custa dinheiro a noite inteira.
Os Databricks SQL Warehouses sustentam consultas de BI e análise SQL. Os SQL warehouses serverless já incluem o custo da VM subjacente na tarifa por DBU, o que simplifica a fatura, mas eleva o preço aparente da DBU. Para volumes esporádicos de consulta, o serverless costuma economizar dinheiro ao eliminar cobranças de cluster ocioso. Para workloads SQL constantes e de alto volume, um warehouse clássico em instâncias reservadas costuma entregar uma economia melhor.
Tarifas aproximadas de DBU por tipo de workload (AWS, planos Standard e Premium)
Tipo de Compute
Plano Standard
Plano Premium
Ideal para
Jobs Compute (AWS)
~US$ 0,07/DBU
~US$ 0,15/DBU
ETL agendado, pipelines em batch
All-Purpose Compute (AWS)
~US$ 0,40/DBU
~US$ 0,55/DBU
Notebooks interativos, trabalho de dev
SQL Warehouse (AWS)
~US$ 0,22/DBU
~US$ 0,22/DBU
Consultas de BI, análise SQL
Serverless SQL (AWS)
N/A
~US$ 0,75/DBU*
Cargas SQL esporádicas/em rajadas
*As tarifas serverless já incluem os custos das VMs subjacentes. Tarifas válidas em março de 2026; confirme os números atuais na página de preços do Databricks antes de orçar, já que variam por região, tipo de instância e provedor de nuvem e estão sujeitas a alterações.
A implicação prática: rodar ETL de produção em um cluster All-Purpose em vez de um cluster Jobs pode aumentar a fatura de DBU desse workload em 3 a 4 vezes, sem nenhuma mudança no processamento subjacente. Identificar e reclassificar esses workloads costuma ser o ajuste de maior ROI que um time de CloudOps consegue fazer.
Custos de armazenamento, transferência de dados e serviços adicionais
As cobranças de infraestrutura de nuvem ficam em cima da linha de DBU. Todo cluster Databricks roda em VMs gerenciadas pelo provedor, e essas VMs são faturadas pelas tarifas padrão. No Azure, um cluster Small SQL Compute custa cerca de US$ 2,64 por hora em DBUs e mais US$ 3,89 por hora em VMs, levando o custo real por hora a passar de US$ 6,50 — mais que o dobro do número que aparece só em DBUs. Times que orçam apenas pela calculadora de preços do Databricks e ignoram o lado da infraestrutura de nuvem subestimam rotineiramente o gasto mensal total em 50% a 200%.
A transferência de dados é mais uma camada. Mover dados entre regiões aciona cobranças de egress do provedor de nuvem. O armazenamento Delta Lake no S3, ADLS ou GCS acumula custos de armazenamento de objetos e transações. Recursos avançados como Delta Live Tables, armazenamento Unity Catalog e AI Foundation Model Serving introduzem dimensões próprias de cobrança. Os recursos serverless, em particular, têm tarifas por DBU mais altas porque embutem o overhead de gestão de infraestrutura no preço da unidade.
Como otimizar custos do Databricks sem frear a engenharia?
Otimizar custos no Databricks não é uma auditoria pontual. Workloads crescem, novos pipelines surgem, times experimentam. As práticas de otimização que aguentam esse dinamismo são as que ficam embutidas em cluster policy, padrões de arquitetura e infraestrutura de monitoramento — não as que viram página de wiki e caem no esquecimento.
Right-sizing de configurações de cluster e escala automatizada
A primeira alavanca é a atribuição por tipo de workload. Todo job de produção em batch que roda em All-Purpose Compute é um custo evitável. Forçar Jobs Compute para workloads agendados via cluster policies elimina essa categoria de desperdício de forma sistemática. As cluster policies também restringem a escolha de tipo de instância, limitando o teto de consumo de DBU por cluster e impedindo o provisionamento ad hoc de nós superdimensionados.
A escolha de família de instância é a segunda dimensão de right-sizing que a maioria dos times subaproveita. A própria documentação de otimização de custos do Databricks mapeia tipos de workload para famílias de instância: memory-optimized para ML e workloads com shuffle pesado, compute-optimized para structured streaming e jobs de manutenção como OPTIMIZE e VACUUM, storage-optimized para análise interativa e em cache, e instâncias GPU apenas para workloads com bibliotecas aceleradas por GPU. Times que adotam instâncias general-purpose para todos os workloads deixam ganhos significativos de preço-performance na mesa.
O auto-termination é o terceiro controle crítico. Clusters All-Purpose usados em trabalho interativo precisam de limites de encerramento agressivos, normalmente de 15 a 30 minutos de tempo ocioso, para evitar cobranças noturnas a partir de uma única sessão de notebook esquecida. Uma ressalva importante: o autoscaling padrão de cluster tem limitações ao reduzir escala em workloads de structured streaming. O Databricks recomenda Lakeflow Spark Declarative Pipelines com autoscaling aprimorado especificamente para esses workloads. Aplicar a pipelines de streaming a recomendação genérica de autoscaling sem essa distinção pode resultar em clusters que não reduzem escala como esperado.
Instâncias Spot oferecem outro caminho de redução de custo para workloads em batch tolerantes a falhas. Os três provedores de nuvem suportam preços Spot para clusters Databricks, e a economia pode ser substancial — frequentemente de 60% a 80% abaixo das tarifas on-demand. O trade-off é o risco de interrupção, o que torna o Spot inadequado para pipelines com janela crítica, mas altamente eficaz para jobs em batch noturnos com lógica de retry embutida.
O formato de armazenamento é uma alavanca de custo que a maioria dos times ignora completamente. Rodar pipelines em Delta Lake em vez de Parquet, ORC ou JSON reduz diretamente o tempo de uso de processamento. As otimizações de performance do Delta Lake aceleram a execução de ETL, o que se traduz em menor tempo de cluster e menos DBUs faturadas para o mesmo volume de dados. Times que herdaram pipelines não-Delta deveriam tratar a migração de formato como uma intervenção legítima de custo, não só um upgrade de confiabilidade ou governança.
Os defaults de armazenamento anexado são outra linha de custo que passa batida. O Databricks provisiona volumes EBS (ou armazenamento em bloco anexado equivalente no Azure e GCP) com cada cluster por padrão, e o tamanho default é generoso. A maioria dos workloads não precisa disso. A não ser que um job envolva operações pesadas de shuffle, transbordamento de memória para disco ou requisitos significativos de armazenamento temporário, esses volumes ficam provisionados, faturados e ociosos. Auditar a configuração default de volume em todas as cluster policies, e reduzir ou remover armazenamento anexado para os jobs que não usam, é uma redução de custo de baixo esforço que se acumula em todos os clusters do workspace.
Runtimes com Photon habilitado reduzem ainda mais o consumo de DBU ao acelerar a execução de consultas em workloads elegíveis. O motor Photon não diminui a tarifa por DBU, mas conclui o mesmo cálculo em menos segundos, cortando o total de unidades faturadas. Todos os SQL warehouses já incluem Photon por padrão. Para pipelines em batch, habilitar Photon em clusters Jobs Compute exige avaliar cada job individualmente, já que o ganho de velocidade varia conforme as características do workload.
Estratégias de monitoramento de custos, alertas e chargeback
Ninguém governa o que não enxerga. O Databricks expõe dados de uso em nível de workspace e cluster por meio de system tables e integrações de logging de custo. Sem puxar esses dados para uma camada de cost analytics que mapeie o consumo a times, projetos ou unidades de negócio, as conversas de otimização ficam abstratas demais para gerar mudança.
A obrigatoriedade de tags em nível de workspace e cluster habilita a atribuição de chargeback. Quando todo cluster carrega uma tag de centro de custo ou projeto, finanças e engenharia conseguem discutir linhas específicas em vez de faturas agregadas. Essa especificidade muda a conversa de "gastamos demais com Databricks" para "o pipeline ETL da feature-X consumiu 40% do orçamento de Jobs Compute do mês passado". Esse tipo de conversa gera ação.
Alertas sobre anomalias de consumo de DBU formam a camada de aviso prévio. Alertas baseados em limiar sobre o gasto diário ou semanal de DBU pegam clusters fora de controle antes que se acumulem em estouros de vários dias. Alertas de orçamento atrelados a tags de workspace dão a cada time a responsabilidade pelo próprio gasto. Atribuição mais alertas mais uma cadência semanal de revisão transformam a gestão de custos em prática contínua, não em projeto de mutirão.
O Databricks Intelligence da DoiT entrega essa camada de visibilidade pronta de fábrica, combinando monitoramento em tempo real do custo de DBU com detecção de anomalias, atribuição por workload e recomendações automatizadas de governança. Times que o usam junto do Cloud Analytics conseguem correlacionar o gasto com Databricks com KPIs de negócio e métricas de velocidade de engenharia, dando ao FinOps o contexto para distinguir gasto desperdiçado de investimento produtivo.
Databricks vs. alternativas: onde ele entrega o melhor custo-benefício?
A comparação certa de plataforma para o Databricks não é sobre as tarifas de DBU em destaque. É sobre o custo total de propriedade em todo o stack: infraestrutura, operação, equipe e aderência de capacidade à sua arquitetura atual.
Comparativo de plataformas: Databricks vs. principais alternativas
Plataforma
Modelo de preço
Pontos fortes
Considerações
Databricks
DBU + infra de nuvem (fatura dupla)
Lakehouse unificado, workloads de ML/Spark
Modelo DBU exige gestão de custo contínua
AWS EMR
Horas de instância EC2 + sobretaxa EMR
Custo por job menor; flexibilidade multi-framework
Maior overhead operacional; UX de dev menos refinada
Google Dataproc
Horas de VM + sobretaxa Dataproc (~1 cent/vCPU/h)
Provisionamento rápido (~90s); nativo do GCP
Melhor custo-benefício só dentro do ecossistema GCP
Azure Synapse
DWU/cDWU ou bytes processados serverless
Integração profunda com Microsoft; BI+Spark unificado
Curva de aprendizado íngreme; confiabilidade variável em escala
O AWS EMR oferece custo de processamento por job menor para workloads em batch pesados em Spark, mas expõe mais complexidade operacional. Times que rodam EMR normalmente investem em gestão dedicada de cluster, tuning e troubleshooting que o Databricks resolve via infraestrutura gerenciada. Um time de analytics de médio porte processando 10 TB por mês pode gastar de US$ 8.000 a US$ 12.000 com Databricks (incluindo a infraestrutura AWS) versus US$ 5.000 a US$ 8.000 com serviços nativos AWS equivalentes — com overhead operacional bem maior absorvido nesse último cenário.
O Google Dataproc provisiona clusters Hadoop e Spark em cerca de 90 segundos a tarifas competitivas por VM, com uma pequena sobretaxa de serviço gerenciado. É econômico para times já bastante imersos no ecossistema GCP, mas falta a experiência de plataforma de analytics unificada (notebooks, SQL workspace, Delta Lake, Unity Catalog) que o Databricks entrega. Quem escolhe Dataproc assume mais montagem da toolchain ao redor.
O Azure Synapse se integra fortemente ao Power BI, ao Azure Data Lake Storage e ao stack de identidade da Microsoft, sendo a escolha natural para organizações já rodando no Azure e ancoradas em T-SQL. Lida bem com workloads SQL serverless e dedicados, mas pipelines complexos de engenharia de dados e workloads de ML frequentemente exigem ferramentas adicionais ou integração de volta com o Databricks.
O Databricks custa mais por DBU que alternativas de infraestrutura pura, mas esse prêmio financia uma plataforma unificada que reduz a complexidade de toolchain, o tempo de onboarding de devs e o peso operacional de gerenciar sistemas separados para engenharia de dados, analytics e ML. Se esse trade-off entrega valor depende do mix de workloads e da maturidade de engenharia do seu time.
Como times de alta performance mantêm o gasto com Databricks previsível em escala?
A complexidade do preço do Databricks não é, por si só, um risco financeiro. Vira um quando os times não têm visibilidade sobre o que está puxando o consumo, não governam a configuração de cluster e tratam revisão de custo como evento trimestral em vez de prática contínua.
Os times que gerenciam o gasto com Databricks com sucesso compartilham algumas propriedades estruturais. Separam tipos de workload por design, usando Jobs Compute para batch de produção por padrão e All-Purpose só para desenvolvimento interativo. Aplicam cluster policies que restringem a seleção de instância e o comportamento ocioso. Mantêm atribuição de custo por time via tags e revisam dados de consumo em cadência semanal para pegar anomalias antes que elas se acumulem.
Essa disciplina operacional escala sem precisar de uma estrutura full-time de FinOps. A infraestrutura de monitoramento certa expõe os sinais. Ferramentas de governança aplicam guardrails sem frear a engenharia. E expertise hands-on traduz padrões de consumo em ajustes concretos à medida que os workloads evoluem.
A DoiT combina essa visibilidade, governança e expertise em uma única plataforma. Times que rodam Databricks em escala usam o Databricks Intelligence para automatizar o monitoramento de custos e a detecção de anomalias, e contam com os especialistas de nuvem da DoiT para traduzir padrões de consumo em recomendações de otimização. O resultado é um gasto com Databricks que escala com o crescimento dos dados sem gerar volatilidade financeira.
Veja como a DoiT ajuda times de CloudOps e FinOps a otimizar continuamente o gasto com Databricks sem frear a inovação. Fale com um especialista.
Perguntas frequentes sobre o preço do Databricks
O que é uma Databricks Unit (DBU)?
Uma DBU é uma unidade normalizada de capacidade de processamento que o Databricks usa para medir e cobrar o consumo de processamento. O uso de DBU é acumulado por segundo enquanto um cluster roda, em uma tarifa que varia conforme o tipo de instância, o tipo de workload (Jobs, All-Purpose, SQL) e o plano. Você multiplica as DBUs consumidas pela tarifa por DBU aplicável para chegar ao custo de software do Databricks. Esse custo aparece em uma fatura separada das cobranças de infraestrutura do seu provedor de nuvem.
Por que minha fatura do Databricks tem cobranças de dois provedores diferentes?
O Databricks cobra pelo software da plataforma em DBUs. Seu provedor de nuvem (AWS, Azure ou GCP) cobra à parte as máquinas virtuais, o armazenamento e o egress de rede que executam seus workloads no Databricks. As duas faturas são independentes e nenhum dos provedores tem visibilidade sobre as cobranças do outro. Times que orçam apenas pela calculadora de preços do Databricks e ignoram o lado da infraestrutura de nuvem regularmente subestimam o custo mensal total em 50% a 200%.
Quanto o Databricks custa por mês para um time típico?
Um time pequeno rodando ETL diário e análise pontual na AWS normalmente gasta de US$ 1.500 a US$ 3.000 por mês somando DBUs do Databricks e infraestrutura de nuvem. Times de médio porte com volumes maiores de dados e workloads mais complexos costumam ficar entre US$ 5.000 e US$ 15.000 por mês ou mais. O custo total depende do volume de workload, da escolha do tipo de processamento, do plano, do provedor de nuvem e de quão bem governado está o comportamento ocioso dos clusters. A variável de maior impacto é se os workloads de batch de produção rodam em Jobs Compute ou em All-Purpose Compute.
Qual é a forma mais rápida de reduzir custos do Databricks?
Três ações entregam a maior economia com mínimo risco de engenharia: mover workloads de batch de produção do All-Purpose Compute para o Jobs Compute (normalmente corta os custos de DBU desses workloads em 60% a 75%), forçar auto-termination em todos os clusters All-Purpose com limite ocioso de 15 a 30 minutos e usar instâncias spot/preemptíveis para jobs em batch tolerantes a falhas. Juntas, essas três mudanças podem reduzir o gasto total com Databricks em 40% a 60% em times que ainda não as aplicaram.
O preço do Databricks varia entre AWS, Azure e GCP?
Sim. O Jobs Compute no plano Standard custa cerca de US$ 0,07 por DBU na AWS, US$ 0,10 no GCP e US$ 0,15 no Azure. O All-Purpose Compute converge mais entre os provedores, em torno de US$ 0,40 por DBU no plano Standard. O Azure também acumula custos adicionais de armazenamento gerenciado para discos e blobs, e suas integrações nativas com a Microsoft adicionam complexidade às comparações diretas de custo entre nuvens. O preço do plano Enterprise envolve tarifas negociadas e não é divulgado publicamente em nenhum provedor.