Quien llega a Snowflake desde una base de datos relacional clásica suele hacer la misma pregunta en la primera semana: «¿Dónde creo los índices?». Durante años la respuesta ha sido: «aquí no hay índices; hay micro-particiones, pruning, claves de clustering y Search Optimization».
Esa respuesta funciona muy bien para cargas analíticas que recorren grandes volúmenes. Pero se queda corta cuando una misma tabla tiene que servir consultas muy selectivas por columnas distintas: buscar un cliente por su NIF, un pedido por su referencia, los movimientos de una cuenta en un rango de fechas… y todo sobre la misma tabla.
El 26 de octubre de 2026 Snowflake anunció la disponibilidad general (GA) de los índices secundarios sobre tablas estándar. En este artículo me centro en lo que más me interesa de esta novedad: cómo cambia la forma de acceder al dato.
El problema: una tabla, un único orden físico
En Snowflake, la eficiencia de una consulta selectiva depende de cuántas micro-particiones puede descartar el optimizador (pruning). Para eso usa los metadatos de mínimos y máximos de cada micro-partición.
Si la tabla está bien ordenada (de forma natural o con una clave de clustering) por la columna que filtras, el pruning es excelente. El problema es que una tabla solo puede tener un orden físico. Si la clusterizas por `fecha_pedido`, las búsquedas por `id_cliente` o por `referencia_externa` tienen que leer muchas más micro-particiones de las necesarias.
Hasta ahora, las alternativas eran:
– Elegir un patrón de acceso ganador y aceptar que los demás fueran más lentos.
– Duplicar la tabla (o crear vistas materializadas) con distinto orden para cada patrón.
– Search Optimization, muy útil para igualdades de alta cardinalidad y búsquedas de texto, pero sin soporte para expresiones ni capacidad de responder la consulta directamente.
Qué aporta un índice secundario
Un índice secundario relaciona los valores indexados con las micro-particiones que los contienen. Con eso, Snowflake puede saltarse todo el dato que la consulta no necesita, sin cambiar el orden físico de la tabla.
Estas son las mejoras clave para el acceso al dato:
1. Varios patrones de acceso sobre la misma tabla
Se pueden crear varios índices secundarios por tabla. La tabla sigue clusterizada para su patrón principal (normalmente el analítico) y cada índice añade un camino de acceso eficiente para otro patrón. Es lo que más cambia en el diseño: ya no hay que elegir un único patrón de acceso por tabla.
-- Patrón principal: análisis por fecha (clave de clustering)ALTER TABLE pedidos CLUSTER BY (fecha_pedido);-- Patrones adicionales: búsquedas puntuales por otras columnasCREATE INDEX idx_pedidos_cliente ON pedidos (id_cliente, fecha_pedido);CREATE INDEX idx_pedidos_referencia ON pedidos (referencia_externa);
2. Búsquedas puntuales y por rango
Los índices secundarios aceleran búsquedas puntuales muy selectivas y consultas por rango. Según la documentación, admiten predicados de igualdad, desigualdad, rango y listas `IN`. Esto los diferencia de Search Optimization, pensado sobre todo para igualdades de alta cardinalidad y funciones de texto o geoespaciales.
SELECT *FROM pedidosWHERE id_cliente = 48213 AND fecha_pedido BETWEEN '2026-01-01' AND '2026-03-31';
3. Índices multicolumna: el orden importa
La clave de un índice es una lista ordenada de columnas o expresiones, y Snowflake usa ese orden al podar micro-particiones con predicados multicolumna. Las primeras expresiones suelen podar mejor. La documentación recomienda:
– Poner primero la columna de filtro más selectiva.
– Usar índices multicolumna cuando las columnas solo son selectivas en combinación.
4. Índices sobre expresiones
La clave puede ser una expresión escalar determinista, no solo una columna. Si tus consultas filtran por `UPPER(email)` o por un `CAST`, puedes indexar exactamente esa expresión:
CREATE INDEX idx_clientes_email ON clientes (UPPER(email));SELECT id_cliente, nombreFROM clientesWHERE UPPER(email) = 'ANA.GARCIA@EJEMPLO.COM';
Es especialmente útil cuando el mínimo y el máximo de la expresión no se pueden deducir de los de la columna original, porque en ese caso el pruning estándar no ayuda.
5. Índices de cobertura con `INCLUDE`
Esta es, para mí, la mejora más interesante a nivel de acceso. Con `INCLUDE` se guardan en el índice columnas adicionales que no sirven para podar, pero que permiten responder la consulta directamente desde el índice, sin leer la tabla base. Es lo que se conoce como índice de cobertura (covering index).
CREATE INDEX idx_pedidos_ref_cov ON pedidos (referencia_externa) INCLUDE (estado, importe_total);-- Puede resolverse solo con el índiceSELECT estado, importe_totalFROM pedidosWHERE referencia_externa = 'PO-2026-000871';
Si la consulta necesita columnas que no están en el índice, no pasa nada: el optimizador sigue usándolo para podar micro-particiones de la tabla base. La regla práctica es: columnas filtradas en la clave, columnas devueltas en `INCLUDE`.
6. Transparente para quien consulta
El índice no se referencia por su nombre en las consultas. El optimizador reescribe la consulta automáticamente, y Snowflake mantiene el índice de forma automática cuando cambian los datos. Para los consumidores (aplicaciones, herramientas de BI, APIs) no cambia nada: el SQL es el mismo y el acceso es más rápido.
Cómo encaja con lo que ya existía
| Índice secundario | Search Optimization | Clústering automático | |
|---|---|---|---|
| Predicados | Igualdad, desigualdad, rango, IN | Igualdad de alta cardinalidad, IN, funciones de texto y geoespaciales | Pruning por rango e igualdad |
| Expresiones | Columnas y expresiones escalares deterministas | Solo columnas | Columnas y expresiones de la clave |
| Responde desde la propia estructura | Sí, con índice de cobertura | No | Sí, porque ordena la tabla base |
| Facturación | Search Optimization | Search Optimization | Clustering automático |
Mi forma de verlo: el clustering define el patrón de acceso principal, los índices secundarios añaden patrones selectivos y Search Optimization cubre búsquedas de texto, geoespaciales y de alta cardinalidad. No compiten; se complementan.
Ojo: no deben confundirse con los índices de las hybrid tables, que son una funcionalidad distinta.
Lo que hay que saber antes de usarlos
Los índices secundarios no son una solución mágica. Estas limitaciones afectan directamente al acceso al dato:
– Un solo índice por tabla en cada escaneo. El optimizador elige el de mayor beneficio esperado y no combina índices. Diseña pensando en el patrón más importante de cada consulta.
– No están garantizados. El optimizador puede decidir no usar un índice aunque pudiera ayudar.
– No se usan en consultas con Time Travel.
– No se admiten en tablas o columnas con políticas de acceso a filas, enmascaramiento, agregación o privacidad. Es la restricción más relevante para el gobierno del dato: en tablas con datos sensibles protegidas por políticas, de momento no hay índices.
– No disponibles en tablas Iceberg, vistas ni vistas materializadas. Solo en tablas estándar.
– No se replican (la documentación lo describe como una limitación temporal).
– Se eliminan automáticamente si se elimina o renombra una columna referenciada o si cambia su tipo de dato.
– Requieren Enterprise Edition o superior y un rol con `OWNERSHIP` sobre la tabla y `ADD SEARCH OPTIMIZATION` sobre el esquema.
Y el coste
El mantenimiento de los índices se factura como parte de Search Optimization. Para hacer seguimiento de los créditos de cada índice se puede consultar la vista `SEARCH_OPTIMIZATION_HISTORY` y filtrar por `INDEX_TYPE = ‘Secondary Index’`.
Dos recomendaciones desde FinOps:
– Mantén las listas de `INCLUDE` cortas. Cada columna adicional aumenta el coste del índice.
– Mide antes y después. Un índice compensa cuando la consulta se ejecuta con frecuencia y es muy selectiva. Para consultas puntuales o poco selectivas, probablemente no.
Conclusión
Para mí, esta GA es un paso importante en una tendencia clara: Snowflake ya no es solo un motor para escanear mucho dato bien, sino también para encontrar poco dato muy rápido. Junto con las hybrid tables y Search Optimization, los índices secundarios acercan la plataforma a escenarios que antes empujaban a llevar los datos a otra base de datos: APIs de datos, aplicaciones que consultan registros concretos, portales de clientes o soporte operativo.
Desde el punto de vista de arquitectura, cambia una decisión de diseño de fondo: ya no hay que elegir un único patrón de acceso por tabla ni duplicar datos para servir varios. Eso significa menos copias, menos pipelines y menos riesgo de que dos versiones del mismo dato se desalineen.
Queda pendiente, eso sí, que puedan convivir con las políticas de enmascaramiento y acceso a filas. Hasta entonces, en tablas con datos sensibles habrá que buscar otras vías.
Podéis leer la nota oficial en la documentación de Snowflake y todos los detalles en la guía de índices secundarios.
¿Tenéis tablas en las que habéis acabado duplicando datos para servir distintos patrones de acceso? Me encantará leer vuestros casos en los comentarios.
Foto de portada gracias a Markus Winkler: https://www.pexels.com/es-es/foto/espacio-para-texto-copy-space-lupa-aumentar-4144768/
