Um guia para criadores sobre como escalar o Databricks Apps

Parabéns, você criou um aplicativo no Databricks Apps e ele passou de alguns usuários para centenas ou milhares em toda a sua organização. Seus usuários querem que ele responda rapidamente e permaneça ativo. Além disso, seu chefe pode não gostar de ter que pagar por computação XLarge em uma pilha de instâncias.

Como criar um aplicativo que seja executado rapidamente, permaneça ativo e lide com a demanda crescente? A resposta intuitiva é mais computação, mas isso só ajuda quando você sabe onde as solicitações gastam seu tempo e se o aplicativo foi criado para dimensionar: seu framework, código assíncrono e capacidade de ser executado em várias instâncias, para que a plataforma possa redimensioná-lo facilmente para cima ou para fora.

Neste guia, analisaremos como dimensionar o Databricks Apps em quatro estágios: design; construção; teste e implantação; e operação (Figura 1). 

O foco deste guia é principalmente o desempenho e a resiliência do aplicativo em escala; ele não aborda a automação de implantação ou a otimização de desempenho e o dimensionamento de outros serviços do Databricks que possam interagir com o aplicativo.

Figura 1: Quatro estágios de dimensionamento de um Databricks App.

Boas decisões de dimensionamento começam antes que qualquer código seja escrito: concorde sobre o que os usuários precisam do aplicativo, decida onde o trabalho será executado e onde os dados residirão.

Comece com metas: pico de usuários e latência

Antes de escolher uma arquitetura, é útil definir quanta carga o aplicativo precisa suportar e como é uma boa experiência. Sugerimos concordar com duas metas principais:

• Desempenho: com que rapidez as ações principais devem responder? Recomendamos metas de latência ponta a ponta com base em um percentil, como o p95, que captura as experiências mais lentas que uma média não mostrará. Inclua a renderização da interface e trate as inicializações a frio separadamente. Para respostas de IA em streaming, o tempo até o primeiro token também importa.
• Escalabilidade: quantos usuários estão ativos no pico, com que frequência eles o usam e quanto crescimento o aplicativo deve suportar? Períodos de pico, como o final do mês, pertencem a esta estimativa porque essa é a carga que o aplicativo deve suportar dentro de suas metas de latência e taxa de erros.

Além disso, decida qual trabalho deve sobreviver a uma reinicialização e verifique se as dependências críticas podem suportar isso. Isso molda como você divide o estado e quantas instâncias você executa.

Em seguida, esboce algumas jornadas de usuário, como abrir um painel ou enviar uma pergunta. Para cada ação, observe os serviços que ela chama, aproximadamente quantas chamadas ela faz e quais dependem umas das outras, com que rapidez ela deve terminar e quão obsoletos os dados em cache podem ser. Essas premissas moldam a arquitetura e as primeiras metas de teste. Assim que um protótipo estiver em execução, você poderá medir as chamadas reais e revisá-las.

Suponha que um varejista dê aos seus 2.000 gerentes de loja um aplicativo para verificar o estoque, apoiado pelo Lakebase. Durante a hora mais movimentada da Black Friday, 200 deles o estão usando ao mesmo tempo. Se cada um fizer duas verificações de estoque por minuto em média, isso dará 400 verificações por minuto. Se cada verificação executar três instruções SQL no Lakebase, espere 1.200 instruções por minuto, ou 20 por segundo em média durante essa hora.

Isso estima a taxa de consulta, não a concorrência. Teste picos e crescimento, valide contra o uso real e faça o orçamento das conexões separadamente (consulte "Faça o orçamento das conexões com o Lakebase").

Design: planeje a arquitetura

Mantenha a computação do aplicativo para servir o aplicativo

A computação do aplicativo existe para servir a interface e coordenar as chamadas, não para fazer o trabalho pesado. Recomendamos enviar cada tipo de trabalho para o serviço construído para ele (Figura 2). Para chamadas de longa duração, execute o trabalho em segundo plano, por exemplo, como um job, e permita que a interface pesquise o status ou receba atualizações em streaming, em vez de manter uma solicitação aberta até que ela termine.

Se o aplicativo precisar executar código que ele não controla, como código escrito por usuários ou gerado por um agente, não o execute no aplicativo. Execute-o no Databricks Sandbox, um ambiente isolado que pode iniciar a partir de uma imagem personalizada, para que o uso de CPU e memória permaneça fora das instâncias que atendem aos usuários.

Figura 2: Onde cada tipo de trabalho é executado e onde o estado reside.

Planeje para escala e escolha um framework

Quando mais pessoas usarem seu aplicativo, você poderá adicionar capacidade de duas maneiras: dimensionamento vertical (scale up) mudando para um tamanho de computação maior, o que dá a cada instância mais CPU e memória, ou dimensionamento horizontal (scale out) adicionando instâncias para compartilhar a carga de solicitações. Com o trabalho pesado sendo executado fora do aplicativo, o que geralmente o limita é quantas solicitações ele pode manipular de uma só vez.

Por exemplo, no caso da Black Friday, cada verificação de estoque é leve, mas as verificações de 200 gerentes de loja podem chegar juntas em picos. Mais instâncias distribuem essas solicitações, e uma instância maior ajuda se o aplicativo puder usar os núcleos extras, normalmente executando mais workers. Um aplicativo que mantém um grande conjunto de dados de referência ou modelo na memória atinge um limite diferente. Uma instância maior fornece a memória necessária; adicionar instâncias não ajuda, porque cada instância carrega sua própria cópia. Você pode começar no Medium e deixar que o teste de carga mais adiante neste guia mostre de que você precisa.

O framework é mais difícil de alterar mais tarde, por isso vale a pena escolhê-lo agora. O Databricks Apps executa aplicativos criados em Python ou Node.js e você não está limitado aos frameworks abaixo. Para a maioria dos novos aplicativos, recomendamos o AppKit, o SDK TypeScript que o databricks apps init e as habilidades de agente do Databricks usam por padrão. Caching, telemetria, lógica de repetição e tratamento de erros vêm integrados, fornecendo um ponto de partida para várias práticas neste guia. O AppKit executa um processo Node.js por instância por padrão, portanto, a maneira mais simples de dimensionar é adicionando instâncias.

Se você já tiver um aplicativo ou se o seu back-end precisar de Python:

• Front-end JavaScript com back-end de API (FastAPI, Flask ou Express): mantenha o estado da interface no navegador e torne o estado do lado do servidor recuperável em workers e instâncias. Os back-ends em Python podem executar vários workers por instância, por exemplo, com Uvicorn ou Gunicorn. Os back-ends em Node.js executam um processo por instância por padrão, portanto, dimensione-os adicionando instâncias.
• Frameworks Streamlit ou Gradio: bons para ferramentas de dados e IA criadas rapidamente em Python. O Streamlit é executado como um único processo e ambos dependem do tratamento de sessões locais da instância, portanto, teste a continuidade da sessão durante reinicializações e redimensionamentos. Para aplicativos que devem ser dimensionados em instâncias com recuperação perfeita, prefira uma das abordagens acima, pois esses frameworks não são recomendados.

O que quer que você escolha, se ele mantiver o estado da sessão na memória do servidor, vale a pena testar o que acontece quando uma sessão é movida para outra instância antes de fazer o dimensionamento horizontal.

Planeje para o estado do aplicativo que sobreviva a reinicializações e redimensionamentos

A maioria dos Databricks Apps mantém algum estado na memória, e isso não tem problema, desde que você saiba quais partes você pode se dar ao luxo de perder. Um primeiro passo útil é listar o que cada sessão contém e o que deve sobreviver a uma reinicialização, depois dividi-lo em estado suave e rígido:

Como essa divisão funciona depende do tipo de aplicativo:

• Agente de IA: mantenha o contexto da conversação, saídas de ferramentas e planos no estado suave enquanto o loop é executado, e salve um ponto de verificação após cada etapa significativa.
• Aplicativo de fluxo de trabalho: faça streaming ou pesquisa (polling) do status em andamento para a interface e salve cada etapa concluída.
• Painel: mantenha valores de filtro, listas de referência e pequenos conjuntos de dados na memória, e salve as preferências do usuário e filtros salvos como estado rígido.

Figura 3: Quando uma sessão é movida, outra instância pode reconstruí-la a partir do estado rígido.

O Databricks Apps mantém cada usuário na mesma instância com base no melhor esforço (afinidade de sessão) e rebalanceia as sessões quando necessário, de modo que qualquer cache por usuário que seu aplicativo mantenha localmente geralmente permaneça disponível. Reinicializações, falhas e alterações de dimensionamento ainda podem mover uma sessão, portanto, outra instância deve ser capaz de reconstruí-la a partir do estado rígido (Figura 3).

Construção: escreva código que seja escalável e sobreviva a reinicializações

Com metas e uma arquitetura em vigor, o próximo passo é escrever código que suporte a carga, inclusive quando uma sessão é movida ou uma instância é interrompida.

Instrumente o aplicativo antes de precisar dele

Recomendamos ativar a telemetria desde o início para que os dados estejam disponíveis antes que você precise deles. A telemetria de aplicativos grava logs, rastreamentos e métricas em tabelas do Unity Catalog por meio do OpenTelemetry. Assim que é ativada para um aplicativo, os logs chegam automaticamente, mas os rastreamentos e as métricas precisam de instrumentação.

Você deve criar spans personalizados em chamadas de SQL, banco de dados, modelo e API para mostrar para onde o tempo está indo. Grave também exceções capturadas no span para que apareçam em seus rastreamentos. Os IDs de rastreamento e de requisição permitem que você acompanhe as requisições de um usuário entre instâncias. Por exemplo, um span em torno de uma chamada SQL:

Use código assíncrono e elimine chamadas desperdiçadas

A maioria dos aplicativos passa o tempo esperando por outro serviço: uma consulta SQL, uma chamada de modelo, uma API externa. Com chamadas bloqueantes, cada espera ocupa um slot de execução durante toda a chamada. Algumas chamadas lentas podem esgotar essa capacidade. É por isso que handlers assíncronos são importantes para trabalhos pesados de E/S. Quando os handlers aguardam chamadas de modelo e de banco de dados, um worker pode continuar atendendo a outras requisições enquanto espera, desde que essas chamadas não sejam bloqueantes. Seus rastreamentos e métricas de sistema mostrarão quando isso se aplica: se a maior parte do tempo de uma requisição for gasta em spans de SQL, de modelo ou de API, e a latência subir com usuários simultâneos enquanto a CPU permanece baixa, as requisições provavelmente estão na fila atrás de chamadas bloqueantes.

Mesmo com o uso de código assíncrono, uma requisição ainda pode ficar lenta se executar consultas uma após a outra. Inicie consultas independentes juntas (por exemplo, com asyncio.gather ou Promise.all), para que a requisição demore quase o mesmo tempo que sua consulta mais lenta. Também vale a pena limitar quantas execuções ocorrem em paralelo, para que uma única requisição não sobrecarregue o data warehouse ou o banco de dados. Geralmente, é melhor combinar consultas do que executar consultas N+1, onde o aplicativo busca uma lista e executa mais uma consulta por item: uma cláusula join ou IN faz o mesmo trabalho em uma ou duas.

Faça cache de dados por usuário por padrão

Um cache acelera um aplicativo, mas também pode vazar dados: um cache em nível de aplicativo não aplica as permissões do Unity Catalog, portanto, um cache compartilhado pode mostrar os dados de um usuário para outro. Limite as chaves de cache pela identidade verificada do usuário e pelos parâmetros de consulta, e por sessão quando necessário; nunca use uma identidade enviada pelo cliente sem verificá-la. Compartilhe dados em cache apenas quando forem idênticos para todos. Para entradas compartilhadas que muitos usuários leem ao mesmo tempo, permita que uma requisição atualize uma entrada expirada enquanto as outras esperam, para que não atinjam o data warehouse todas juntas. O cache do AppKit, por exemplo, remove duplicatas de perdas de cache concorrentes dentro de cada instância.

Em reinicializações de containers de aplicativos ou mudanças de sessão

Colocar o design de estado leve e estado persistente em prática resume-se a algumas recomendações:

• Persista tudo o que precisar sobreviver a uma reinicialização ou implantação. A memória pura é boa para caches descartáveis, mas não para trabalhos que os usuários não podem perder.
• Salve checkpoints onde você não gostaria de repetir o trabalho e torne as etapas idempotentes para que uma nova tentativa seja segura.
• Torne as sessões portáteis para que qualquer instância possa reconstruí-las a partir do estado persistente (Figura 3). Recarregue apenas o necessário e faça o cache para evitar leituras repetidas.
• Aplicativos de navegador obtêm afinidade de sessão automaticamente. Para clientes de API com estado, envie um cabeçalho X-Routing-Key estável e use-o com base no que controla o estado leve. Escolha uma chave específica o suficiente para distribuir a carga, como uma conversa ou ID de usuário, em vez de um ID de locatário. O cliente define o cabeçalho, portanto, use-o apenas para roteamento, nunca para decidir quem é o usuário.
• Espere que as conexões com o banco de dados também caiam. Elas caem quando o banco de dados é reinicializado ou passa por failover. Reconecte com backoff limitado e jitter para que as instâncias não se reconectem todas de uma vez e causem uma tempestade de conexões. Antes de tentar uma gravação novamente, verifique o banco de dados para confirmar se ela já não foi concluída.
• Mantenha a inicialização leve. Cada reinicialização, implantação e nova instância paga o custo de carregar modelos ou datasets, aquecer caches e abrir pools antes de poder atender ao tráfego. Evite grandes instalações e chamadas externas bloqueantes na inicialização, e carregue recursos pesados apenas quando necessário.

Encerre de forma graciosa

Quando você reimplanta um aplicativo, o Databricks envia SIGTERM e, em seguida, SIGKILL se o aplicativo não tiver sido encerrado em até 15 segundos. Essa janela é para os checkpoints finais. O trabalho importante já deve ter sido salvo durante a operação normal.

Como exemplo, com o FastAPI, o Uvicorn conclui as requisições abertas antes de executar a limpeza do ciclo de vida. save_in_progress_sessions() substitui sua própria função que salva o trabalho inacabado:

Isso pressupõe um pool assíncrono (por exemplo, AsyncConnectionPool do psycopg). O tutorial do Apps-to-Lakebase usa um pool síncrono, que você fecha sem await.

Defina o --timeout-graceful-shutdown do Uvicorn abaixo de 15 segundos (por exemplo, 10) para que uma requisição de longa duração não consuma o tempo do checkpoint, e teste o encerramento com sua própria carga de trabalho. O plugin Lakebase do AppKit fecha seus pools no encerramento; qualquer salvamento de checkpoint personalizado ainda precisa caber na mesma janela.

Teste e implante: teste de carga e dimensionamento para o pico

Figura 4: Métricas do sistema durante um teste de carga escalonado: a latência saltou na última etapa, enquanto a CPU e a memória permaneceram abaixo dos limites.

Antes do lançamento, um teste de carga ajudará você a transformar suas estimativas em decisões mais próximas da realidade: o tamanho da instância, os workers por instância e a quantidade de instâncias.

Como realizar testes de carga em Databricks Apps

Recomendamos realizar testes de carga antes da produção, usando jornadas de usuário reais no pico esperado. Uma ferramenta como o Locust relata requisições por segundo, percentis de latência e a taxa de falhas em cada etapa, e o teste é aprovado ou reprovado com base nas metas de latência e taxa de erro que você definiu para as ações principais. Enquanto o teste é executado, as métricas de sistema integradas do aplicativo mostram requisições por minuto, latência, CPU e memória em relação aos seus limites, para que você possa ver qual limite o aplicativo atinge primeiro (Figura 4).

Aumente os usuários simultâneos em etapas até que a vazão pare de aumentar ou a latência e as taxas de erro ultrapassem suas metas. Vale a pena testar vários tamanhos de instância e quantidades de workers, pois uma configuração maior nem sempre é mais rápida. Também sugerimos testar a recuperação em um ambiente de teste: pare e inicie o aplicativo (não apenas reimplemente ou altere a quantidade de instâncias durante uma execução) e verifique se os usuários podem continuar, quanto tempo a recuperação leva e se algum trabalho foi perdido. Para aplicativos de agentes, o guia de teste de carga orienta sobre como testar primeiro com um LLM simulado para medir a vazão do próprio aplicativo e, em seguida, com o modelo real para a latência de ponta a ponta.

O próprio gerador de carga pode ser o gargalo: ele pode ficar sem CPU ou conexões primeiro, e erros de autenticação ou respostas de limite de taxa podem parecer lentidão. O que importa são requisições bem-sucedidas e sustentadas dentro da sua meta de latência, e não um pico breve.

O teste de carga também deve mostrar se os serviços por trás do aplicativo acompanham o ritmo. Se o data warehouse começar a enfileirar ou um endpoint de modelo limitar a taxa, dimensione esse serviço, e não o aplicativo.

Escolha o tamanho da instância

O Databricks Apps oferece três tamanhos: Medium (o padrão, até 2 vCPUs e 6 GB), Large (até 4 vCPUs e 12 GB) e XLarge (até 12 vCPUs e 48 GB). O tamanho ideal depende de qual limite seu aplicativo atinge primeiro; comece com o Medium e deixe o teste de carga mostrar a você:

Quantos workers cada instância deve executar?

Workers são processos de servidor dentro de cada instância. Para servidores Python que oferecem suporte a esse modelo, você define a contagem na inicialização (por exemplo, uvicorn --workers 2), e ela se aplica por instância.

Um único worker pode deixar a CPU ociosa, mas workers extras também competem por CPU e memória. No benchmark do nosso guia de testes de carga, o Medium obteve um desempenho melhor com dois workers do que com quatro, e o Large entregou aproximadamente 2,2x o throughput do Medium. Considere os pontos de partida documentados, dois workers no Medium ou oito no Large, como um primeiro palpite: o benchmark simulou o LLM e foi limitado pela CPU, e um aplicativo real que depende principalmente de chamadas de modelos pode aproveitar melhor os workers extras. Escolha a contagem a partir do seu próprio teste de carga, com o modelo real.

Quantas instâncias o aplicativo deve executar?

Com o dimensionamento horizontal, você define a contagem de instâncias por conta própria. O limite padrão é de cinco instâncias por aplicativo, e o seu representante da Databricks pode aumentá-lo se o teste de carga mostrar que você precisa de mais. Dimensione a contagem para os picos esperados e o crescimento. O aplicativo continua funcionando enquanto a contagem é alterada, e o custo de computação é dimensionado linearmente com a contagem de instâncias. Se você estiver convertendo um aplicativo existente, teste-o primeiro em uma cópia.

Para maior disponibilidade, recomendamos pelo menos duas instâncias, com capacidade suficiente para lidar com o pico de carga após a perda de uma: se o pico precisar de duas instâncias, execute três. Instâncias extras protegem contra falhas em uma instância, e não contra problemas nos serviços por trás do aplicativo.

Defina o orçamento para as conexões com o Lakebase

Para um Databricks App que se conecta ao Lakebase com OAuth, recomendamos começar com um pool de conexões do lado do aplicativo na string de conexão padrão (não PgBouncer) do banco de dados. Ele reutiliza conexões e busca novas credenciais de OAuth à medida que abre novas, conforme o tutorial do Apps para Lakebase mostra para Python. Defina o tempo limite do pool para deixar tempo suficiente para a consulta em si antes do prazo final da requisição.

Essas conexões se acumulam, portanto, planeje o orçamento antes de adicionar instâncias ou workers. Com um pool por worker, o limite superior é instâncias × workers por instância × tamanho máximo do pool: cinco instâncias com oito workers e um pool máximo de dez podem abrir até 400 conexões. Adicione outros clientes e quaisquer conexões que o aplicativo abra em nome dos usuários, depois compare o total com o limite documentado do banco de dados, deixando margem para implantações, quando versões antigas e novas forem executadas lado a lado.

Consultas em nome do usuário (OBO) exigem capacidade de identidade. Isso significa que cada usuário que consulta o Lakebase como si mesmo precisa de sua própria função (role) do Postgres, e o Lakebase permite 500 funções por ramificação. Para bases de usuários maiores, decida antecipadamente quais consultas realmente precisam de acesso por usuário. Adicionar instâncias não altera esse limite. Quando as permissões em nível de grupo forem suficientes, uma função do Postgres para um grupo Databricks permite que seus membros se conectem com seus próprios tokens OAuth, de modo que uma única função cubra todo o grupo.

Faça rollouts sem interrupções e rollbacks com segurança

Para aplicativos dimensionados horizontalmente, o Databricks atualiza uma instância primeiro e o restante após o sucesso dela, para que o aplicativo continue funcionando. Ainda vale a pena verificar após cada implantação se o aplicativo está íntegro e se as sessões se recuperam. Manter o código no Git significa que você pode fazer o rollback reimplementando uma tag ou um commit conhecido e funcional. Durante um rollout, versões antigas e novas são executadas lado a lado, portanto, mantenha os formatos de banco de dados e de ponto de verificação legíveis por ambos, e não remova campos de que a versão anterior precise até ter certeza de que não fará o rollback.

Operação: monitorar, diagnosticar e corrigir com base em dados

Após o lançamento, o trabalho se torna um ciclo: encontre a etapa mais lenta, corrija-a e meça novamente. É por isso que mantemos a telemetria ativada em produção. Em aplicativos dimensionados horizontalmente, a visualização Ao vivo na guia Logs mostra uma instância de cada vez; com a telemetria ativada, o recurso Logs de Telemetria do App mostra todas elas.

Quando algo estiver lento, rastreie a requisição de ponta a ponta (Figura 5).

Figura 5: Onde uma requisição gasta seu tempo e os principais gargalos.

Comece pelo sintoma

Estes são os sintomas que vemos com mais frequência e para onde eles geralmente apontam:

Configure alertas de integridade

Recomendamos planejar os alertas como parte da configuração: decida quem será notificado quando o app cair e alimente app_status.state e compute_status.state da API de Apps em sua ferramenta de monitoramento. O status do app por si só não prova que os usuários conseguem trabalhar, portanto, verifique também uma jornada do usuário representativa, com sua latência e suas taxas de erro. Permita pequenas alterações de estado durante as implantações ao definir limites.

Resumo

Dimensionar Databricks Apps significa dimensionar todo o caminho da requisição, e não apenas o servidor de aplicativos: defina metas de latência e de pico de carga, envie trabalhos pesados para o serviço criado para isso, mantenha o estado recuperável e deixe que os testes de carga e a telemetria decidam para onde vai a capacidade. Adicione recursos de computação quando as medições mostrarem que você precisa deles, e não como uma reação imediata.

Para ir mais fundo, leia como criar aplicativos de dados e IA prontos para produção com Databricks Apps e Lakebase. Para obter mais detalhes, consulte Práticas recomendadas para Databricks Apps e Registro em log e monitoramento para Databricks Apps na documentação. Para padrões de arquitetura por tipo de aplicativo, como ferramentas internas, copilotos de IA e fluxos de trabalho baseados em agentes, assista a Criando aplicativos melhores e Aplicativos com estado para milhares de usuários do Data + AI Summit 2026.

FAQs

Como faço para dimensionar um Databricks App?

Dimensione-o em quatro etapas: design, criação, teste e implantação, e operação. Defina primeiro as metas de latência e de pico de carga, mantenha a computação do app para atender à UI e escreva código assíncrono com estado recuperável. Em seguida, deixe que os testes de carga e a telemetria decidam se você deve escalar verticalmente para uma instância maior ou horizontalmente para mais instâncias.

Devo escalar verticalmente ou horizontalmente o meu Databricks App?

Isso depende de qual limite o aplicativo atinge primeiro. Escale horizontalmente adicionando instâncias quando as solicitações chegam em picos ou um aplicativo de processo único está vinculado a um único núcleo. Escale verticalmente para Large ou XLarge quando o aplicativo precisar de mais memória ou quando executar vários workers que podem usar núcleos extras.

Quais tamanhos de instância os Databricks Apps oferecem?

Os Databricks Apps oferecem Medium (o padrão, com até 2 vCPUs e 6 GB), Large (com até 4 vCPUs e 12 GB) e XLarge (com até 12 vCPUs e 48 GB). Comece com o Medium e deixe um teste de carga mostrar de qual tamanho seu aplicativo precisa.

Como faço para manter as sessões de usuário funcionando quando um aplicativo é reiniciado ou escalado?

Divida o estado da sessão em estado maleável, que pode ser refeito, e estado rígido, que é armazenado de forma durável em tabelas do Lakebase ou Unity Catalog. Os Databricks Apps mantêm cada usuário na mesma instância da melhor forma possível, mas reinicializações e escalonamento ainda podem mover uma sessão, portanto, qualquer instância deve ser capaz de recriá-la a partir do estado rígido.

Quantas conexões do Lakebase um aplicativo escalado pode abrir?

Com um pool por worker, o limite superior é instâncias × workers por instância × tamanho máximo do pool. Por exemplo, cinco instâncias com oito workers e um pool máximo de dez podem abrir até 400 conexões. Compare esse total com o limite documentado do banco de dados e deixe margem para implantações.

Tudo pronto para levar seu aplicativo de alguns usuários para milhares? Confira as Melhores práticas para Databricks Apps e o escalonamento horizontal para Databricks Apps na documentação.

"Explorar Databricks Apps" →

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original