DuckDB es un motor de base de datos analítico que funciona embebido en tu proceso, sin servidor, igual que SQLite pero orientado a OLAP en lugar de OLTP. La versión 1.0 salió en enero de 2024 y desde entonces ha tenido lanzamientos relevantes: la 1.1 en septiembre de 2024 y la 1.2 en marzo de 2025. Si trabajas con datos y todavía no lo has probado, merece la pena que lo hagas.
Qué lo hace diferente de SQLite y de PostgreSQL
SQLite es una base de datos embebida orientada a OLTP: buena para transacciones, registros pequeños, aplicaciones móviles. DuckDB está diseñado para lo contrario: escanear columnas enteras, hacer agregados sobre millones de filas, procesar ficheros Parquet y CSV directamente. Usa almacenamiento columnar en lugar de por filas, lo que es mucho más eficiente para queries analíticas que leen pocas columnas pero muchas filas.
PostgreSQL, en cambio, es un servidor completo con soporte multiusuario, transacciones ACID, replicación... todo lo que necesitas para producción. DuckDB no tiene servidor, no tiene usuarios, no tiene red. Lo abres como librería desde tu código y listo.
Empezar en Python es trivial
-- En Python: pip install duckdb
import duckdb
# Consulta en memoria directamente
resultado = duckdb.sql("SELECT 42 AS respuesta").df()
# Leer un CSV sin importarlo antes
df = duckdb.sql("SELECT * FROM 'datos.csv' WHERE año > 2022").df()
# Leer Parquet directamente
duckdb.sql("SELECT categoria, SUM(ventas) FROM 'ventas.parquet' GROUP BY categoria").show()
# Abrir o crear un fichero .duckdb persistente
con = duckdb.connect('mi_base.duckdb')
con.execute("CREATE TABLE IF NOT EXISTS ventas AS SELECT * FROM 'ventas.csv'")
con.sql("SELECT COUNT(*) FROM ventas").show()
La integración con pandas es directa: el método .df() devuelve un DataFrame. También puedes pasar un DataFrame a DuckDB directamente en la query:
import pandas as pd
import duckdb
df = pd.read_csv('datos.csv')
# DuckDB puede referenciar el dataframe directamente
resultado = duckdb.sql("SELECT * FROM df WHERE valor > 100").df()
Leer y escribir Parquet
Una de las cosas donde DuckDB brilla especialmente es en el trabajo con Parquet. Puede leer ficheros Parquet directamente desde disco o desde S3, aplicar predicados y proyecciones antes de cargar en memoria, y exportar resultados a Parquet:
-- Leer Parquet con predicado (solo lee las columnas y filas necesarias) SELECT fecha, SUM(importe) AS total FROM 'ventas_2024.parquet' WHERE region = 'ES' GROUP BY fecha; -- Exportar resultado a Parquet COPY (SELECT * FROM ventas WHERE año = 2024) TO 'ventas_2024.parquet' (FORMAT PARQUET);
SQL analítico completo
DuckDB soporta un SQL muy completo: funciones de ventana, CTEs, WITH RECURSIVE, PIVOT, UNPIVOT, QUALIFY (para filtrar por funciones de ventana sin subquery), y extensiones propias. Muchas de estas cosas son más engorrosas de hacer en pandas o en Polars, y DuckDB las resuelve con SQL estándar.
-- QUALIFY: filtrar por funcion de ventana sin subquery SELECT * FROM ventas QUALIFY ROW_NUMBER() OVER (PARTITION BY region ORDER BY importe DESC) = 1;
Cuándo tiene sentido usarlo
DuckDB va bien cuando:
- Tienes ficheros CSV, Parquet o JSON que quieres analizar sin montarte un servidor.
- Trabajas en notebooks de análisis de datos y el pandas/Polars puro se queda corto para queries complejas.
- Tienes datasets de tamaño medio (hasta ~100GB en una sola máquina con suficiente RAM) y Spark es demasiado para el problema.
- Quieres aprovechar todos los núcleos de la CPU sin configurar nada: DuckDB paraleliza automáticamente.
No es la opción correcta para aplicaciones con muchas escrituras concurrentes, para datos que necesitan consistencia ACID estricta en producción, o para entornos multiusuario. Para eso sigue siendo PostgreSQL.
Si tu flujo de trabajo ya usa pandas o Polars, DuckDB se integra muy bien. El artículo sobre pandas 2.x y Polars en 2026 cubre los casos de uso de cada uno, y DuckDB ocupa un nicho complementario: cuando el SQL es más cómodo que la API de DataFrames. Y si trabajas con LLMs y necesitas consultar embeddings almacenados en ficheros locales, DuckDB también puede hacer ese trabajo de forma eficiente antes de que llegues a necesitar pgvector en PostgreSQL.
Imagen: Pexels / Negative Space