Puedes reducir el costo del Databricks Serverless SQL Warehouse si asocias cada problema del workload con el control adecuado. El auto-stop reduce el tiempo de ejecución inactivo, el tamaño del warehouse afecta el rendimiento de cada consulta individual y el máximo de clústeres controla cuánta concurrencia puede absorber el warehouse.
El desafío es que esas señales suelen mezclarse. Un warehouse que permanece activo entre trabajos cortos no necesita más potencia. Los workloads que esperan capacidad pueden necesitar más clústeres en lugar de un warehouse más grande. Power BI DirectQuery también puede seguir generando actividad en Databricks SQL incluso cuando el SQL en sí ya está bien optimizado.
En este artículo te mostramos cómo distinguir esos casos, comparar Serverless con Pro y Classic usando el costo total en lugar de solo el precio por DBU, y elegir el ajuste que corresponde al comportamiento que realmente estás viendo. Estas decisiones a nivel de warehouse forman parte del framework completo de optimización de costos de Databricks, donde el dimensionamiento, la utilización, la atribución y la automatización trabajan en conjunto.
TL;DR
- El auto-stop reduce las ventanas de inactividad entre ráfagas de trabajo SQL.
- El tamaño del warehouse controla el cómputo disponible para cada consulta individual.
- El máximo de clústeres controla cuánta demanda concurrente puede atender el warehouse.
- Serverless, Pro y Classic deben compararse por el costo total del workload, no solo por el precio del DBU.
- El modo de conexión de Power BI puede cambiar de forma significativa la actividad del SQL Warehouse cuando se usa
DirectQuerypara una actualización en vivo que el negocio no necesita.
Por qué los arranques y el tiempo de inactividad disparan el costo del SQL Warehouse de Databricks
Tu factura del SQL Warehouse puede crecer más rápido de lo que sugiere el tiempo de ejecución de las consultas, porque los trabajos cortos siguen generando arranques y ventanas de actividad. Con las alertas programadas, el problema es fácil de pasar por alto: varias consultas de menos de un minuto con programaciones distintas pueden mantener activo un Databricks Serverless SQL Warehouse mucho más tiempo del que corre el SQL en sí. La configuración puede agravar esa brecha. Un despliegue de bundle documentado omitió auto_stop_mins y terminó con un valor de 120 minutos, aunque la documentación actual de los Declarative Automation Bundles de Databricks indica un valor predeterminado de 10 minutos para Serverless.
Nuestra lectura es que un error de configuración oculto puede hacer más daño que una consulta lenta, porque se repite en cada ejecución. ¿Cuánto de tu factura del SQL Warehouse proviene de consultas costosas y cuánto de configuraciones que nadie ha vuelto a revisar? El mismo patrón aparece en los cinco hábitos que mueven una factura de Databricks y en el framework completo de optimización de costos.
Tipos de SQL warehouse en Databricks: Serverless vs. Pro vs. Classic
Entre los principales tipos de SQL warehouse, Serverless tiene el precio visible por Databricks Unit (DBU) más alto porque incluye la infraestructura subyacente. Un Pro SQL warehouse tiene un precio por DBU más bajo, y Classic el más bajo de todos, pero ambos cobran la infraestructura de nube por separado. Con el cómputo serverless, Databricks gestiona la infraestructura subyacente en lugar de exponer un cargo de infraestructura de nube aparte que tú debas administrar.
Por ejemplo, los precios de lista publicados de AWS Premium en US East sitúan a Serverless en alrededor de $0.70 por DBU, a un Pro SQL warehouse en $0.55 y a Classic en $0.22, con datos de 2026. Los precios reales pueden variar según la nube, la región, la edición y el contrato. Esas cifras corresponden a un ejemplo de precios de una sola región, pero muestran por qué el precio por DBU por sí solo no te dice qué opción cuesta menos en total.
| Tipo | Precio relativo por DBU | Facturación de infraestructura | Arranque en frío | Mejor para |
|---|---|---|---|---|
| Serverless | El más alto | Incluida | Normalmente segundos | Workloads de BI interactivos y DirectQuery con demanda en ráfagas |
| Pro | Intermedio | Se factura por separado | Normalmente minutos | Workloads de BI predecibles que requieren funciones Pro |
| Classic | El más bajo | Se factura por separado | Normalmente minutos | Workloads programados y predecibles |
Los Serverless SQL warehouses se adaptan mejor a la demanda en ráfagas porque pueden arrancar en segundos y responder rápido cuando la demanda cambia. Databricks SQL Serverless también usa Intelligent Workload Management (IWM) para predecir las necesidades de recursos de las consultas y gestionar la capacidad a medida que la demanda cambia. Eso reduce la necesidad de mantener el cómputo activo solo para evitar un arranque lento.
Los Pro SQL warehouses y los Classic SQL warehouses son más relevantes cuando la demanda es predecible. Databricks recomienda estos SQL warehouses para trabajos programados de Import o Extract, donde la demanda es más fácil de planificar y el arranque rápido importa menos. Un Pro SQL warehouse agrega capacidades más allá de Classic SQL, que sigue siendo la opción de menor DBU para casos de uso más simples.
La comparación útil es el costo total de ejecutar el workload, incluyendo la infraestructura, el comportamiento de arranque y cuánto tiempo necesita permanecer activo el warehouse. Mirar solo el precio por DBU genera el mismo error de ver solo la mitad de la factura y puede hacer que Serverless parezca más caro de lo que realmente es.
Si quieres comparar esos costos a nivel de warehouse, SELECT for Databricks te ayuda a ver de dónde provienen el gasto, el dimensionamiento y la utilización del SQL Warehouse antes de cambiar la configuración.
Auto-stop en el SQL warehouse: los mínimos de la UI y la API son distintos
Los Serverless SQL warehouses te dan más margen para acortar el auto-stop que los Pro o Classic SQL warehouses. En la UI de Databricks, el mínimo para Serverless es de cinco minutos, mientras que la API y los Declarative Automation Bundles permiten bajar auto_stop_mins hasta un minuto. Pro y Classic tienen un mínimo de 10 minutos.
El valor más corto no siempre es el correcto. Un auto-stop de un minuto puede funcionar para trabajos programados aislados, mientras que los workloads interactivos de DirectQuery pueden beneficiarse de permanecer activos más tiempo. Nuestra guía de auto-stop para SQL Warehouse recomienda alrededor de 10 minutos para el uso general de SQL.
Puedes configurar un warehouse Serverless con un auto-stop de un minuto usando la CLI de Databricks:
databricks warehouses edit <WAREHOUSE_ID> \ --auto-stop-mins 1Los valores predeterminados también dependen de cómo creas los SQL warehouses. La UI de Databricks usa por defecto 10 minutos para Serverless y 45 minutos para Pro o Classic, mientras que los Declarative Automation Bundles usan 10 minutos para Serverless y 120 minutos para Pro o Classic. Define auto_stop_mins de forma explícita para que el despliegue no dependa del valor predeterminado de esa ruta de configuración.
Dimensionar un SQL warehouse: tamaño vs. clústeres
En Databricks SQL, el tamaño del warehouse y el máximo de clústeres resuelven problemas de rendimiento distintos. El tamaño controla el cómputo disponible para cada consulta individual, mientras que el máximo de clústeres controla cuánta demanda concurrente puede atender el warehouse. Serverless también usa Intelligent Workload Management para manejar de forma automática parte de la asignación de recursos.
Usa las señales de las consultas y de la cola para decidir qué control ajustar:
| Síntoma | Control a ajustar |
|---|---|
| Una sola consulta es lenta o vuelca muchos datos a disco | Aumenta el tamaño del warehouse |
| Las consultas pasan mucho tiempo esperando capacidad | Aumenta el máximo de clústeres |
| El pico de Queued Queries se mantiene por encima de cero | Revisa tanto el tamaño del warehouse como el máximo de clústeres |
| Largos intervalos de inactividad entre consultas | Reduce el auto-stop |
El pico de Queued Queries no identifica por sí solo la solución exacta. Un waiting_at_capacity_duration_ms alto apunta a presión de capacidad, mientras que las consultas lentas o que vuelcan muchos datos a disco apuntan más al tamaño del warehouse. Nuestra preferencia es confirmar si la presión es a nivel de consulta o de concurrencia antes de agregar más cómputo.
El tiempo de inactividad apunta a un problema distinto. Cuando la capacidad es suficiente durante la ejecución de las consultas pero el warehouse permanece activo entre trabajos, el auto-stop es el ajuste que hay que inspeccionar.
Cuándo Power BI DirectQuery cambia la ecuación de costos del serverless
Power BI DirectQuery puede generar mucha más actividad en el warehouse de lo que el dashboard en sí parece justificar, porque cada interacción puede enviar otra consulta a Databricks. Databricks recomienda los Serverless SQL Warehouses para DirectQuery y LiveQuery, con una ventana de auto-stop de 15 a 30 minutos para workloads interactivos.
Cuando el negocio solo necesita actualizaciones cada pocos minutos, los modelos Import o Hybrid pueden reducir la actividad de Databricks SQL al atender más interacciones del reporte desde el propio Power BI. Las vistas materializadas también pueden precalcular el trabajo SQL repetido, aunque sus actualizaciones siguen usando cómputo serverless aparte.
Nuestra opinión es que DirectQuery debería ser uno de los primeros lugares a investigar cuando el costo de Serverless parece desconectado de la complejidad del dashboard. Antes de culpar a los precios de Serverless, verifica si el modo de conexión de BI está generando más actividad de la que realmente exige la frecuencia de actualización que el negocio necesita.
Cómo convertir estos controles en una configuración concreta
Mantener el costo del SQL Warehouse bajo control requiere visibilidad continua sobre el dimensionamiento, el tiempo de inactividad y la presión de capacidad. Nuestra vista de costos del SQL Warehouse reúne esas señales para que puedas ver dónde la configuración merece otra revisión.
Nuestro Automated Savings puede ajustar la cantidad de workers y las configuraciones de autoescalado compatibles de los SQL Warehouses a medida que la demanda cambia. El auto-stop sigue siendo un control aparte, así que conviene revisar auto_stop_mins después de cada despliegue y auditar los modos de conexión de BI cuando la actividad ya no coincide con la frecuencia de actualización que requiere el negocio.
El siguiente nivel de ahorro consiste en convertir esas revisiones en un hábito operativo. La decisión es si revisar a mano el tamaño, el máximo de clústeres, el auto-stop y los modos de BI sigue siendo una apuesta justificable, o si ese trabajo recurrente está empezando a acumularse.
Costo del Databricks Serverless SQL Warehouse: qué ajustar primero
Asocia el ajuste con la señal que estás viendo: las ventanas de inactividad apuntan al auto-stop, la presión de la cola a la capacidad, las consultas individuales lentas al tamaño del warehouse y la actividad inesperada de BI al modo de conexión. Compara Serverless, Pro y Classic por el costo total, no solo por el precio del DBU.
Revisa la evidencia antes de cambiar la configuración. Nuestra vista de costos de Databricks reúne el costo del SQL Warehouse, el dimensionamiento, el cómputo inactivo y la utilización para que veas qué ajuste merece atención primero.