Una de las preguntas que más repito en reuniones de arquitectura es: «¿esto necesita un pool dedicado o basta con serverless?». Azure Synapse Analytics ofrece dos motores SQL con filosofías opuestas: uno reserva capacidad de cómputo por adelantado, el otro cobra solo por lo que consultas. Elegir mal el modelo no rompe nada, pero sí la factura a final de mes.
Dos motores, dos filosofías
Azure Synapse Analytics viene con dos tipos de pool SQL. El dedicated SQL pool reserva un conjunto fijo de recursos de cómputo, medidos en Data Warehouse Units (DWU), que tú aprovisionas y escalas manualmente. El serverless SQL pool, en cambio, no reserva nada: es un servicio de consulta sobre tu data lake, siempre disponible, que escala de forma automática según la consulta que lances.
Dedicated SQL pool: capacidad reservada
En el modelo dedicated, defines cuántas DWU quieres y Synapse reparte ese cómputo entre un número de nodos de proceso (hasta 60). Las tablas se distribuyen físicamente entre esos nodos siguiendo una estrategia de sharding: hash (mejor rendimiento para joins y agregaciones sobre tablas grandes), round robin (la más simple, habitual en tablas de staging) o replicated (la tabla entera se copia en cada nodo, ideal para catálogos pequeños).
Pagas por la capacidad reservada, esté en uso o no, aunque puedes pausar el pool para dejar de pagar cómputo (los datos se conservan) y reanudarlo cuando lo necesites. Es el modelo pensado para cargas predecibles: un almacén de datos corporativo con ventanas de carga e informes conocidos, donde interesa un rendimiento sostenido y consistente.
Serverless SQL pool: pago por consulta
El serverless SQL pool viene activado por defecto en cualquier workspace de Synapse, sin necesidad de aprovisionar nada. Permite consultar directamente ficheros Parquet, Delta Lake, CSV o JSON en tu Azure Data Lake Storage usando T-SQL, sin cargarlos antes en ninguna tabla. Según la documentación oficial, no hay coste por recursos reservados: solo se paga por los datos que las consultas procesan, medido en terabytes escaneados.
Esto lo hace ideal para exploración ad-hoc: un analista que quiere entender rápido la forma de un fichero nuevo, un data scientist que necesita un vistazo antes de decidir cómo modelar los datos, o un informe de Power BI construido directamente sobre el lake sin pasar por un proceso de carga previo.
| Aspecto | Dedicated SQL pool | Serverless SQL pool |
|---|---|---|
| Cómputo | Reservado, medido en DWU | Automático, sin aprovisionar |
| Coste | Por capacidad reservada (pausable) | Por TB de datos escaneados |
| Datos | Deben cargarse en tablas del pool | Se consultan in-situ en el data lake |
| Caso de uso típico | Almacén de datos con carga e informes recurrentes | Exploración ad-hoc, prototipado, logical data warehouse |
Un ejemplo de dominio genérico: imagina una plataforma de ventas que cada noche carga sus tickets a un dedicated SQL pool para alimentar el informe financiero mensual, mientras el equipo de analítica usa el serverless SQL pool para explorar, sin avisar a nadie, un nuevo fichero de eventos de navegación que acaba de aterrizar en el data lake.
Modelo de costes, a alto nivel
La diferencia de coste no es solo de precio, es de forma. El dedicated SQL pool tiene un coste previsible y recurrente mientras el pool está activo, independientemente de si lo usas o no en un momento dado; pausarlo cuando no hace falta es la palanca principal de ahorro. El serverless SQL pool tiene coste cero cuando nadie consulta nada, y crece de forma proporcional al volumen de datos escaneado por cada consulta, lo que premia formatos columnares eficientes (como Parquet o Delta) y estrategias de filtrado que reduzcan el dato leído.
- Si la carga es predecible y recurrente, el dedicated SQL pool suele salir más barato que pagar por TB escaneado cada vez.
- Pausa el dedicated SQL pool fuera de horario de carga e informes para no pagar cómputo ocioso.
- Usa el serverless SQL pool como primera parada para explorar un dataset nuevo antes de decidir si merece una tabla dedicada.
- En serverless, prioriza formatos columnares (Parquet, Delta) frente a CSV: reducen el volumen de TB escaneado y por tanto el coste.
- No dupliques esfuerzo: usa serverless como capa lógica de consulta sobre el lake en vez de replicar datos en un dedicated pool «por si acaso».
Antes de decidir qué pool consulta tus datos, ¿cómo llegan realmente hasta el data lake que Synapse va a leer?
Leer el artículo sobre los tipos de Integration Runtime en Azure Data Factory