DuckDB avanzado: el motor que aplasta a los demás en analítica

Ya conoces DuckDB de la sección de SQL: escribiste consultas en él durante doce lecciones y viste por qué no es lo mismo que PostgreSQL. Ahora vamos a exprimir su potencial real. Porque DuckDB no es solo "un SQLite para analítica" — es un motor que en benchmarks destruye a PostgreSQL en queries analíticas por un factor de 10x-100x. Y en esta sección vas a necesitar todo ese poder: window functions, CTEs, planes de ejecución y queries sobre millones de filas.

Y una cosa nueva que vas a usar desde el primer ejercicio: generate_series, que fabrica filas de la nada. Sirve para inventarte datos de prueba sin depender de nadie, y es una de las costumbres que más agradece un analista cuando quiere probar una idea antes de pedir datos de verdad.

En esta lección vas a entender POR QUÉ DuckDB es tan rápido, qué formatos puede leer nativamente (spoiler: Parquet, JSON, CSV y archivos remotos por HTTP) y vas a verificar que el dataset de práctica del e-commerce está listo para las 10 lecciones que siguen.

### ¿Por qué DuckDB es BRUTAL para analítica?

Hay tres razones técnicas por las que DuckDB aplasta a PostgreSQL en queries analíticas. No es magia — es ingeniería pensada para un problema diferente:

1. 01.Almacenamiento columnar: PostgreSQL guarda filas completas juntas. Si tu query solo necesita 2 de 50 columnas, lee las 50 de todas formas. DuckDB guarda cada columna por separado — solo lee lo que necesita. En una tabla con 50 columnas y 10 millones de filas, eso puede ser 25x menos datos leídos.
2. 02.Ejecución vectorizada: PostgreSQL procesa fila por fila (tuple-at-a-time). DuckDB procesa bloques de miles de valores a la vez (vectores de 2048 elementos), aprovechando las instrucciones SIMD del procesador. Es la diferencia entre llevar las compras una bolsa a la vez vs llenar el maletero de un tirón.
3. 03.Sin overhead de servidor: PostgreSQL gestiona conexiones, permisos, WAL, vacuuming, locks... DuckDB no tiene nada de eso. Toda la potencia del CPU se dedica a TU query. Es un F1 sin airbags — peligroso en producción, perfecto en tu laboratorio.

Y aquí está la prueba de que la razón es el almacenamiento por columnas y no una magia general: si obligas a DuckDB a leer las 50 columnas (sumando todas), tarda 1,66 segundos — prácticamente lo mismo que PostgreSQL leyendo 2. La ventaja no está en que DuckDB calcule más rápido: está en que no lee lo que no le has pedido. Y eso te da una regla práctica para tu trabajo: cuanto más ancha sea la tabla y menos columnas pidas, más gana DuckDB. Con una tabla de 3 columnas la diferencia casi desaparece. Con una de 200, es abismal.

### Features avanzadas: leer cualquier formato sin importar

DuckDB puede leer datos de múltiples formatos sin necesidad de cargarlos primero en una tabla. Esto es enormemente práctico: llegas a un directorio con archivos Parquet, CSVs y JSONs y puedes hacer queries directamente sobre ellos:

1-- Leer un CSV directamente (sin CREATE TABLE)
2SELECT * FROM read_csv_auto('ventas_2024.csv') LIMIT 5;
3
4-- Leer Parquet (formato columnar comprimido)
5SELECT region, SUM(importe) AS total
6FROM read_parquet('data/ventas/*.parquet')
7GROUP BY region;
8
9-- Leer JSON
10SELECT * FROM read_json_auto('eventos.json') LIMIT 10;
11
12-- ¿Leer archivos REMOTOS por HTTP!
13SELECT COUNT(*) FROM read_csv_auto(
14    'https://raw.githubusercontent.com/..../data.csv'
15);

Esto es lo que hace de DuckDB la herramienta preferida para husmear en un data lake: te dan una carpeta con ficheros Parquet y puedes consultarlos sin cargar nada en ninguna parte. No lo vas a necesitar en este curso, pero cuando alguien te pase un Parquet de dos gigas y te pregunte "¿qué hay aquí dentro?", ya sabes que la respuesta es una línea de SQL.

### El dataset de práctica: tu e-commerce en esta sección

Para las siguientes 10 lecciones trabajarás con el mismo dataset de e-commerce que ya usaste en SQL básico. Las tablas ya están cargadas en la plataforma. Vamos a hacer un repaso rápido de lo que tienes disponible:

1-- Ver todas las tablas disponibles
2SHOW TABLES;
3
4-- Conteo rápido de cada tabla
5SELECT 'clientes' AS tabla, COUNT(*) AS filas FROM clientes
6UNION ALL SELECT 'pedidos', COUNT(*) FROM pedidos
7UNION ALL SELECT 'productos', COUNT(*) FROM productos
8UNION ALL SELECT 'categorias', COUNT(*) FROM categorias
9UNION ALL SELECT 'lineas_pedido', COUNT(*) FROM lineas_pedido
10UNION ALL SELECT 'vendedores', COUNT(*) FROM vendedores
11UNION ALL SELECT 'ventas_diarias', COUNT(*) FROM ventas_diarias
12UNION ALL SELECT 'ventas_mensuales', COUNT(*) FROM ventas_mensuales
13UNION ALL SELECT 'empleados', COUNT(*) FROM empleados;

• ▹clientes (5.000 filas): id, nombre, email, ciudad, fecha_registro, canal_adquisicion, es_vip
• ▹pedidos (20.000 filas): id, cliente_id, producto_id, cantidad, fecha, importe, estado
• ▹productos (200 filas): id, nombre, categoria_id, precio, stock
• ▹categorias (5 filas): id, nombre, descripcion — tabla de referencia para productos
• ▹lineas_pedido (30.000 filas): id, pedido_id, producto_id, cantidad, precio_unitario — detalle de cada pedido
• ▹vendedores (10 filas): id, nombre, equipo, categoria, ventas — para ejercicios de rankings
• ▹ventas_diarias (365 filas): fecha, importe_diario — para acumulados y medias móviles
• ▹ventas_mensuales (24 filas): fecha, importe — para LAG/LEAD y comparaciones temporales
• ▹empleados (100 filas): id, nombre, departamento, salario, fecha_contratacion

### Verificación: tu primer query analítico cruzado

Vamos a hacer una query que cruza clientes con pedidos para verificar que todo funciona. Esta query usa GROUP BY, JOIN, filtros y agregaciones — todo lo que ya sabes de la sección de SQL:

1-- Resumen por ciudad: clientes, pedidos completados y gasto
2SELECT 
3    c.ciudad,
4    COUNT(DISTINCT c.id) AS clientes_unicos,
5    COUNT(p.id) AS total_pedidos,
6    ROUND(SUM(p.importe), 0)::INTEGER AS gasto_total,
7    ROUND(AVG(p.importe), 2) AS ticket_medio
8FROM clientes c
9JOIN pedidos p ON p.cliente_id = c.id
10WHERE p.estado = 'completado'
11GROUP BY c.ciudad
12ORDER BY gasto_total DESC;

### Lo que vas a dominar en esta sección

Las window functions son lo que separa al junior del senior en cualquier entrevista técnica de datos. Son la respuesta a "quiero el detalle Y el resumen al mismo tiempo". En las próximas lecciones vas a:

1. 01.Entender el problema que resuelven las window functions (lección 2)
2. 02.Dominar ROW_NUMBER, RANK y DENSE_RANK (lección 3)
3. 03.Comparar con LAG y LEAD (lección 4)
4. 04.Calcular acumulados y medias móviles con FRAMES de ventana (lección 5)
5. 05.Medir comparaciones temporales y entender el efecto base (lección 6)
6. 06.Entender estacionalidad, tendencia y calendario: comparar como es debido (lección 7)
7. 07.Construir embudos de conversión: dónde se pierde la gente (lección 8)
8. 08.Aplicar segmentación RFM: recencia, frecuencia y valor (lección 9)
9. 09.Leer planes de ejecución con EXPLAIN (lección 10)
10. 10.Proyecto final: análisis de cohortes y retención de clientes (lección 11)

DuckDB va a ser tu compañero durante toda esta sección. Su velocidad te permite iterar rápido: prueba una query, modifícala, vuelve a ejecutar. Sin esperas, sin frustraciones. El motor está listo — ahora toca dominar las window functions.