Totalmente de acuerdo. En muchos entornos, el costo de los SQL Warehouses puede crecer rápidamente, pero normalmente no se trata solamente de “usar un Warehouse más pequeño”. Yo revisaría el problema en varias capas:
Optimizar las queries primero
Antes de reducir el tamaño del Warehouse, identificar las consultas que consumen más DBU/tiempo. Revisaría especialmente SELECT *, joins innecesarios, scans completos y consultas que procesan grandes volúmenes de datos repetidamente.
Aprovechar correctamente Delta Lake
Revisar el diseño de las tablas, particionamiento cuando realmente aporta valor, estadísticas y el mantenimiento de las tablas. Una tabla bien optimizada puede reducir significativamente la cantidad de datos que necesita leer el Warehouse.
Warehouse sizing y auto-stop
No mantener un Warehouse sobredimensionado para el workload real. Configurar correctamente el auto-stop también puede tener un impacto importante cuando existen períodos largos de inactividad.
Concurrency y workload separation
Si tenemos BI, dashboards, ad-hoc queries y procesos de reporting compartiendo el mismo Warehouse, puede ser mejor separar workloads. De lo contrario, terminamos pagando por capacidad que realmente no estamos utilizando eficientemente.
Revisar dashboards y consultas repetitivas
Este punto suele pasar desapercibido. Un dashboard que ejecuta muchas queries cada vez que alguien lo abre puede generar bastante consumo. Aquí conviene revisar refresh intervals, queries y, cuando corresponda, usar resultados/materializaciones en lugar de recalcular todo constantemente.
Medir antes de optimizar
Usaría los datos de system tables y Query History para identificar exactamente dónde se está generando el consumo. No optimizaría “a ciegas”.
En mi experiencia, la mayor oportunidad normalmente está en combinar query optimization + diseño de datos + sizing correcto + control de concurrencia, en lugar de simplemente reducir el tamaño del SQL Warehouse.
La pregunta interesante sería: ¿qué porcentaje de vuestro costo viene realmente de capacidad/concurrencia y cuánto viene de queries ineficientes? Esa separación ayuda bastante a definir dónde atacar primero.
🇬🇧 English
Absolutely agree. In many environments, SQL Warehouse costs can grow quickly, but the solution is usually not simply to “use a smaller Warehouse.” I would look at the problem across several layers:
Optimize the queries first
Before reducing Warehouse size, identify the queries consuming the most DBUs/time. I would specifically look for SELECT *, unnecessary joins, full scans, and queries repeatedly processing large volumes of data.
Make proper use of Delta Lake
Review table design, partitioning where it actually provides value, statistics, and table maintenance. A well-optimized table can significantly reduce the amount of data the Warehouse needs to scan.
Warehouse sizing and auto-stop
Avoid keeping a Warehouse oversized for the actual workload. Properly configuring auto-stop can also have a meaningful impact when there are long periods of inactivity.
Concurrency and workload separation
If BI, dashboards, ad-hoc queries, and reporting workloads are all sharing the same Warehouse, separating workloads may be more efficient. Otherwise, you can end up paying for capacity that isn't being used efficiently.
Review dashboards and repetitive queries
This is often overlooked. A dashboard that executes many queries every time someone opens or refreshes it can generate significant consumption. Review refresh intervals and query patterns and, where appropriate, consider caching/materialization rather than recalculating everything repeatedly.
Measure before optimizing
I would use system tables and Query History to identify exactly where the consumption is coming from. I wouldn't optimize blindly.
In my experience, the biggest opportunity usually comes from combining query optimization + data design + correct Warehouse sizing + concurrency management, rather than simply reducing the Warehouse size.
The interesting question is: what percentage of your cost is actually coming from capacity/concurrency versus inefficient queries? Separating those two helps determine where to focus the optimization effort first.
