# DuckDB desde cero para analizar CSV y datos

**Categoría:** Bases de datos · **Nivel:** Intermedio · **Lectura:** 19 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/bases-de-datos/duckdb-desde-cero-para-analizar-csv-y-datos/

## Respuesta rápida

**DuckDB** es una base de datos **analítica** que corre **dentro de tu propio programa**, sin servidor ni instalación de servicios, y su gran atractivo es que puede lanzar consultas **SQL directamente sobre archivos** —un [CSV](../como-importar-un-csv-en-mysql-y-postgresql/index.md), varios CSV a la vez, o el formato Parquet— **sin necesidad de importarlos** primero a ninguna tabla. Antes, para analizar un CSV grande con SQL había que montar una base de datos, crear las tablas, importar los datos y recién entonces consultar; DuckDB borra todos esos pasos: le señalás el archivo en el propio `FROM` de la consulta (por ejemplo `SELECT * FROM 'ventas.csv'`) y responde. Se la suele describir como «el **SQLite** de la analítica»: igual que SQLite es una base de datos que vive en un archivo y se embebe en tu aplicación sin servidor, DuckDB es embebida y sin servidor, pero con una diferencia clave de **propósito**. SQLite es **transaccional** (OLTP): está pensada para muchas operaciones pequeñas —insertar un pedido, leer un usuario—, típicas de una aplicación. DuckDB es **analítica** (OLAP): está pensada para consultas que **recorren millones de filas y agregan** —sumas, promedios, agrupaciones sobre columnas enteras—, típicas del análisis de datos. La razón de su velocidad para eso es que DuckDB es **columnar**: guarda y procesa los datos **por columnas** en lugar de por filas, de modo que cuando una consulta solo necesita 2 de 50 columnas, lee únicamente esas 2 y se saltea el resto, y además procesa los valores en bloques aprovechando el procesador moderno. ¿Cuándo encaja DuckDB? Cuando querés **analizar datos con SQL** —explorar un CSV, cruzar archivos, hacer informes— de forma rápida y local, sin la ceremonia de montar un servidor. ¿Cuándo no? Como base de datos **de una aplicación con muchos usuarios escribiendo a la vez**: para eso están las bases transaccionales como [PostgreSQL o MySQL](../relacional-vs-no-relacional/index.md). DuckDB es gratuita, de código abierto, y se usa desde Python, R, la línea de comandos y muchos otros lenguajes.

## Qué es DuckDB

**DuckDB** es una base de datos **analítica** y **embebida**: corre dentro de tu propio programa —tu script de Python, tu sesión de R, tu terminal— sin que tengas que instalar ni arrancar ningún servidor. Es gratuita y de código abierto. La comparación más útil para entenderla es con SQLite.

> **«El SQLite de la analítica»**
>
> A DuckDB se la describe a menudo como **«el SQLite** de la analítica», y la frase captura muy bien qué es. Igual que SQLite, DuckDB es **embebida y sin servidor**: no es un servicio separado al que te conectás por la red, sino una biblioteca que vive *dentro* de tu aplicación, así que no hay nada que instalar como servicio, ni usuarios, ni puertos, ni configuración de red. Añadís la librería y ya tenés una base de datos completa con SQL. La diferencia está en el **propósito**, y es la distinción clave entre dos grandes familias de bases de datos. SQLite es **transaccional** —lo que se llama OLTP, procesamiento de transacciones en línea—: está optimizada para muchas **operaciones pequeñas**, como insertar una fila, leer un registro concreto o actualizar un campo, que es lo que hace una aplicación normal. DuckDB es **analítica** —OLAP, procesamiento analítico en línea—: está optimizada para **consultas que recorren y agregan grandes cantidades de datos**, como sumar todas las ventas de un año, calcular promedios por región o cruzar millones de filas, que es lo que hace el análisis de datos. No compiten: resuelven trabajos distintos. Si estás construyendo una aplicación que guarda pedidos, querés SQLite (o una base transaccional). Si estás *analizando* esos pedidos —explorando, agregando, sacando informes—, querés DuckDB.

## Consultar archivos directo

La característica que enamora a quien analiza datos es que DuckDB consulta **archivos directamente**, sin el paso previo de importar. El contraste con el flujo clásico:

| Flujo clásico | Con DuckDB |
|---|---|
| Montar/arrancar un servidor de base de datos | Nada: la base vive dentro de tu programa |
| Crear las tablas con sus columnas | DuckDB deduce las columnas del propio archivo |
| Importar el CSV a la tabla y esperar | Se salta: consultás el archivo directamente |
| Recién entonces, lanzar la consulta SQL | `SELECT ... FROM 'archivo.csv'` y listo |

> **Atención**
>
> En SQL normal, después del `FROM` se escribe el nombre de una *tabla* que existe dentro de la base de datos. La idea central de DuckDB para análisis es que ahí podés poner directamente la **ruta de un archivo**: `SELECT * FROM 'ventas.csv'` lee el CSV en el acto, deduce solo las columnas y sus tipos, y ejecuta la consulta como si fuera una tabla. Y no se queda en un archivo: podés consultar **muchos a la vez** con un comodín —`FROM 'datos/*.csv'` lee todos los CSV de una carpeta como si fueran una sola tabla—, cruzar un CSV con otro con un `JOIN`, o leer el formato **Parquet**, que es un formato de archivo columnar comprimido, muy habitual en análisis de datos, con el que DuckDB es especialmente veloz porque comparten filosofía. Todo esto sin cargar nada en memoria de golpe ni duplicar los datos en una tabla: DuckDB lee del archivo lo que la consulta necesita. Para el trabajo diario de exploración —«¿cuántas filas hay?», «¿cuál es el promedio por categoría?», «crucemos estos dos exports»— esto elimina literalmente todos los pasos de preparación y deja solo la pregunta. Es la diferencia entre tardar media hora en poder preguntar algo y preguntarlo en el primer segundo. Si más adelante querés el flujo clásico de [importar CSV](../como-importar-un-csv-en-mysql-y-postgresql/index.md) a tablas persistentes, DuckDB también lo hace; pero la magia para el análisis es que casi nunca hace falta.

## Por qué es tan rápida

DuckDB es notablemente rápida en consultas analíticas, y la razón principal es que es **columnar**. Merece la pena entender qué significa, porque es lo que la distingue de una base transaccional como SQLite.

> **Atención**
>
> Una base de datos **por filas** (como SQLite o MySQL) guarda cada registro completo junto: toda la fila de un pedido —su id, fecha, cliente, importe, región y otras cuarenta columnas— va seguida en el disco. Eso es ideal cuando querés *un registro entero* («dame el pedido 12345 con todos sus campos»), que es el trabajo transaccional. Pero el análisis casi nunca quiere filas enteras: quiere **una operación sobre unas pocas columnas de muchísimas filas** («el promedio del importe de todos los pedidos», «las ventas totales por región»). Una base **columnar** como DuckDB guarda los datos **por columnas**: todos los importes juntos, todas las regiones juntas, cada columna en su propio bloque. Esto le da dos ventajas enormes para el análisis. Primero, cuando una consulta solo necesita 2 de 50 columnas, DuckDB **lee únicamente esas 2** y se saltea las otras 48 —muchísimo menos trabajo de disco y memoria—, mientras que una base por filas tendría que leer las filas completas aunque solo use dos campos. Segundo, al tener todos los valores de una columna juntos y del mismo tipo, DuckDB los **comprime muy bien** y los procesa en **bloques** (muchos valores de una vez), aprovechando cómo funcionan los procesadores modernos en lugar de ir valor por valor. La suma de leer menos, comprimir más y procesar en bloque es lo que hace que una agregación sobre millones de filas que en una base por filas tardaría bastante, en DuckDB sea casi instantánea. Es la misma razón por la que el formato **Parquet** —también columnar— y DuckDB se llevan tan bien.

## Cuándo encaja (y cuándo no)

- **Sí:** explorar y analizar archivos CSV o Parquet con SQL, de forma rápida y local.
- **Sí:** hacer informes, agregaciones y cruces de datos sin montar un servidor.
- **Sí:** desde Python o R, como motor analítico dentro de un cuaderno o script.
- **No:** como base de datos de una aplicación con muchos usuarios escribiendo a la vez; para eso, PostgreSQL o MySQL.
- **No:** para muchas operaciones transaccionales pequeñas; ahí encaja SQLite u otra transaccional.
- **Recordá:** DuckDB no reemplaza a tu base de producción; es una herramienta de análisis que convive con ella.
- **Aprovechá:** Parquet en lugar de CSV cuando los datos son grandes; DuckDB vuela con formatos columnares.

## Preguntas frecuentes

**¿Qué es DuckDB?**
DuckDB es una base de datos analítica y embebida, gratuita y de código abierto, que corre dentro del propio programa del usuario, como un script de Python, una sesión de R o una terminal, sin necesidad de instalar ni arrancar ningún servidor ni servicio separado. Ser embebida significa que no es un servicio independiente al que uno se conecta por la red, sino una biblioteca que vive dentro de la aplicación, de modo que no hay nada que instalar como servicio, ni usuarios, ni puertos, ni configuración de red, sino que basta con añadir la librería para disponer de una base de datos completa con lenguaje SQL. La forma más útil de entender qué es DuckDB es compararla con SQLite, hasta el punto de que se la describe con frecuencia como el SQLite de la analítica. Al igual que SQLite, DuckDB es embebida y sin servidor. La diferencia está en el propósito, que corresponde a la distinción clave entre dos grandes familias de bases de datos. SQLite es transaccional, lo que se conoce como procesamiento de transacciones en línea u OLTP, y está optimizada para muchas operaciones pequeñas, como insertar una fila, leer un registro concreto o actualizar un campo, que es lo que hace una aplicación normal. DuckDB, en cambio, es analítica, lo que se conoce como procesamiento analítico en línea u OLAP, y está optimizada para consultas que recorren y agregan grandes cantidades de datos, como sumar todas las ventas de un año, calcular promedios por región o cruzar millones de filas, que es lo propio del análisis de datos. Por tanto, las dos no compiten, sino que resuelven trabajos distintos, y de hecho pueden convivir. Si uno está construyendo una aplicación que guarda pedidos, la opción adecuada es SQLite o una base transaccional; si en cambio está analizando esos pedidos, explorándolos, agregándolos o sacando informes, la opción adecuada es DuckDB. Su gran atractivo para el análisis es que puede lanzar consultas SQL directamente sobre archivos como CSV o Parquet sin necesidad de importarlos primero, y su velocidad se debe a que es una base de datos columnar, es decir, que guarda y procesa los datos por columnas en lugar de por filas. DuckDB se puede usar desde muchos lenguajes, como Python, R o la línea de comandos.

**¿Puedo consultar un CSV con DuckDB sin importarlo?**
Sí, la característica más destacada de DuckDB para el análisis de datos es precisamente que permite consultar un archivo CSV directamente sin necesidad de importarlo primero a ninguna tabla, lo que elimina todos los pasos de preparación del flujo clásico. En el flujo tradicional para analizar un CSV grande con SQL, había que montar o arrancar un servidor de base de datos, crear las tablas con sus columnas y tipos, importar el contenido del CSV a esas tablas esperando a que se cargara, y solo entonces se podía lanzar la consulta. DuckDB borra todos esos pasos gracias a una idea central muy sencilla. En SQL normal, después de la palabra FROM se escribe el nombre de una tabla que existe dentro de la base de datos. En DuckDB, en ese mismo lugar se puede poner directamente la ruta de un archivo, de modo que una consulta como seleccionar todo desde ventas punto csv lee el archivo CSV en el acto, deduce automáticamente cuáles son sus columnas y de qué tipo son, y ejecuta la consulta como si el archivo fuera una tabla. Además, esta capacidad no se limita a un único archivo. Se pueden consultar muchos archivos a la vez usando un comodín, de manera que indicar una ruta como datos barra asterisco punto csv lee todos los archivos CSV de una carpeta como si fueran una sola tabla. También se puede cruzar el contenido de un CSV con el de otro mediante una operación de unión o JOIN, o leer archivos en formato Parquet, que es un formato de archivo columnar y comprimido muy habitual en el análisis de datos, con el que DuckDB es especialmente veloz porque comparten la misma filosofía columnar. Todo esto se hace sin cargar todos los datos en memoria de golpe ni duplicarlos en una tabla, ya que DuckDB lee del archivo solo lo que la consulta necesita. Para el trabajo diario de exploración de datos, como averiguar cuántas filas hay, cuál es el promedio por categoría o cruzar dos exportaciones, esta capacidad elimina literalmente toda la preparación y deja únicamente la pregunta, lo que supone la diferencia entre tardar mucho tiempo en poder preguntar algo y poder preguntarlo de inmediato. Si más adelante se prefiere el flujo clásico de importar el CSV a tablas persistentes, DuckDB también lo permite, pero la ventaja para el análisis es que casi nunca hace falta.

**¿Qué diferencia hay entre DuckDB y SQLite?**
La diferencia entre DuckDB y SQLite no está en cómo se despliegan, ya que ambas son bases de datos embebidas y sin servidor que viven dentro de la aplicación, sino en su propósito, ya que SQLite es una base de datos transaccional pensada para muchas operaciones pequeñas, mientras que DuckDB es una base de datos analítica pensada para consultas que recorren y agregan grandes cantidades de datos. Ambas comparten la naturaleza embebida, lo que significa que no son servicios separados a los que uno se conecta por la red, sino bibliotecas que se integran dentro del programa, sin necesidad de instalar servicios, gestionar usuarios ni configurar puertos, bastando con añadir la librería para tener una base de datos con SQL. Esta similitud es la que lleva a describir a DuckDB como el SQLite de la analítica. La diferencia fundamental es el tipo de trabajo para el que cada una está optimizada, que corresponde a las dos grandes familias de bases de datos. SQLite es transaccional, dentro de la categoría del procesamiento de transacciones en línea, conocida como OLTP, y está optimizada para operaciones pequeñas y frecuentes, como insertar un registro, leer una fila concreta por su identificador o actualizar un campo, que es el patrón de uso típico de una aplicación que gestiona datos de usuarios, pedidos o configuraciones. DuckDB es analítica, dentro de la categoría del procesamiento analítico en línea, conocida como OLAP, y está optimizada para consultas que recorren muchísimas filas y las agregan, como calcular sumas, promedios, agrupaciones o cruces sobre columnas enteras, que es el patrón de uso típico del análisis de datos. Esta diferencia de propósito se refleja en el diseño interno de cada una. SQLite almacena los datos por filas, lo que es ideal para recuperar registros completos, mientras que DuckDB los almacena por columnas, lo que la hace mucho más rápida cuando una consulta solo necesita unas pocas columnas de muchas filas, ya que puede leer nada más esas columnas y procesarlas en bloques comprimidos. En la práctica, las dos herramientas no compiten sino que se complementan, ya que resuelven necesidades distintas. Si se está construyendo una aplicación que guarda y modifica datos constantemente, la opción adecuada es SQLite o una base transaccional. Si lo que se quiere es analizar datos, explorarlos, agregarlos o generar informes, la opción adecuada es DuckDB. Incluso pueden convivir, usando SQLite o una base transaccional para la aplicación y DuckDB para analizar los datos que esta genera.

**¿Por qué DuckDB es tan rápida para analizar datos?**
DuckDB es tan rápida para analizar datos principalmente porque es una base de datos columnar, es decir, que guarda y procesa los datos organizados por columnas en lugar de por filas, un diseño que resulta ideal para las consultas analíticas y que la distingue de las bases de datos transaccionales como SQLite. Para entender la ventaja conviene ver cómo funciona lo contrario. Una base de datos organizada por filas, como SQLite o MySQL, guarda cada registro completo junto en el disco, de modo que toda la información de un pedido, su identificador, su fecha, su cliente, su importe, su región y cualquier otra columna, va almacenada de forma contigua. Esto es ideal cuando se quiere recuperar un registro entero, como pedir un pedido concreto con todos sus campos, que es el trabajo transaccional habitual. Sin embargo, el análisis de datos casi nunca quiere filas enteras, sino que quiere realizar una operación sobre unas pocas columnas de muchísimas filas, como calcular el promedio del importe de todos los pedidos o las ventas totales por región. Una base columnar como DuckDB guarda los datos por columnas, es decir, todos los importes juntos, todas las regiones juntas, cada columna en su propio bloque. Esto le proporciona dos grandes ventajas para el análisis. La primera es que, cuando una consulta solo necesita unas pocas columnas de entre muchas, por ejemplo dos de cincuenta, DuckDB lee únicamente esas columnas y se salta todas las demás, lo que supone muchísimo menos trabajo de lectura de disco y de memoria, mientras que una base por filas tendría que leer las filas completas aunque solo utilizara dos de sus campos. La segunda ventaja es que, al tener todos los valores de una misma columna juntos y del mismo tipo, DuckDB los puede comprimir muy bien y procesarlos en bloques, es decir, muchos valores de una sola vez, aprovechando la forma en que funcionan los procesadores modernos, en lugar de ir procesando valor por valor. La combinación de estas tres cosas, leer menos datos, comprimir mejor y procesar en bloque, es lo que hace que una agregación sobre millones de filas, que en una base por filas llevaría un tiempo considerable, en DuckDB sea casi instantánea. Esta misma filosofía columnar es la razón por la que DuckDB se lleva especialmente bien con el formato de archivo Parquet, que también es columnar, y por la que resulta tan eficiente al consultar ese tipo de archivos.

**¿Cuándo conviene usar DuckDB y cuándo no?**
Conviene usar DuckDB cuando se quiere analizar datos con SQL de forma rápida y local, como explorar archivos CSV o Parquet, hacer informes, agregaciones y cruces de datos sin montar un servidor, o usarla como motor analítico dentro de un cuaderno o script de Python o R, y no conviene usarla como base de datos de una aplicación con muchos usuarios escribiendo a la vez ni para muchas operaciones transaccionales pequeñas, casos para los que están las bases de datos transaccionales. Los escenarios en los que DuckDB encaja bien comparten la naturaleza analítica de su diseño. Es ideal para explorar y analizar archivos CSV o Parquet con SQL de forma rápida y local, aprovechando que puede consultar los archivos directamente sin importarlos. Es muy útil para hacer informes, agregaciones y cruces de datos sin la ceremonia de montar y mantener un servidor de base de datos. Y funciona muy bien integrada en lenguajes como Python o R, actuando como motor analítico dentro de un cuaderno de análisis o de un script, lo que la convierte en una herramienta habitual para científicos y analistas de datos. Por el contrario, hay casos en los que DuckDB no es la opción adecuada. No conviene usarla como base de datos de una aplicación en producción con muchos usuarios escribiendo datos al mismo tiempo, ya que ese es un trabajo transaccional con alta concurrencia de escritura para el que están diseñadas bases como PostgreSQL o MySQL. Tampoco conviene para cargas compuestas de muchas operaciones transaccionales pequeñas, como insertar, leer o actualizar registros individuales de forma constante, escenario en el que encaja mejor SQLite u otra base transaccional. Es importante entender que DuckDB no reemplaza a la base de datos de producción de una aplicación, sino que es una herramienta de análisis que convive con ella, de modo que una organización puede tener sus datos en una base transaccional y usar DuckDB para analizarlos. Además, para sacarle el máximo partido, conviene aprovechar el formato Parquet en lugar de CSV cuando los datos son grandes, ya que al ser un formato columnar y comprimido DuckDB rinde especialmente bien con él. En resumen, la regla es usar DuckDB para el análisis de datos, donde brilla por su velocidad y su comodidad, y reservar las bases transaccionales para el funcionamiento de las aplicaciones.

**¿DuckDB reemplaza a mi base de datos de producción?**
No, DuckDB no reemplaza a la base de datos de producción de una aplicación, sino que es una herramienta de análisis pensada para convivir con ella y complementarla, ya que cada una está diseñada para un tipo de trabajo distinto. La base de datos de producción de una aplicación, como PostgreSQL, MySQL o SQLite, es normalmente transaccional, es decir, está optimizada para el procesamiento de transacciones en línea u OLTP, que consiste en muchas operaciones pequeñas y frecuentes, como insertar un pedido, leer los datos de un usuario o actualizar el estado de un registro, a menudo con muchos usuarios haciéndolo al mismo tiempo. Este tipo de base de datos gestiona la concurrencia de escrituras, la integridad de los datos y las transacciones, y es la que da servicio a la aplicación en funcionamiento. DuckDB, en cambio, es una base de datos analítica, optimizada para el procesamiento analítico en línea u OLAP, que consiste en consultas que recorren y agregan grandes volúmenes de datos, como informes, promedios, sumas y cruces sobre muchas filas. Su diseño columnar y su capacidad de consultar archivos directamente la hacen excelente para el análisis, pero no está pensada para ser el almacén principal de una aplicación con mucha escritura concurrente. Por ello, el papel natural de DuckDB no es sustituir a la base de producción, sino trabajar junto a ella en las tareas de análisis. Un patrón habitual es que los datos vivan en la base de datos transaccional de producción, que se encarga del día a día de la aplicación, y que para analizarlos se exporten o se lean con DuckDB, que realiza las consultas analíticas pesadas de forma rápida y sin cargar de trabajo a la base de producción, lo que además evita que las consultas de análisis, que pueden ser costosas, interfieran con el rendimiento de la aplicación en funcionamiento. De este modo, ambas herramientas se reparten el trabajo según sus fortalezas: la base transaccional garantiza el funcionamiento fiable de la aplicación, y DuckDB aporta la potencia analítica para explorar y entender los datos. En resumen, DuckDB se suma al conjunto de herramientas de datos como el motor de análisis, sin desplazar a la base de datos que sostiene la aplicación en producción.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Bases de datos](https://underc0de.org/foro/bases-de-datos/). Análisis de datos y SQL.
2. **Underc0de, blog.** [Blog de Underc0de](https://blog.underc0de.org/). Herramientas de datos.

### Documentación oficial

1. **DuckDB.** [DuckDB Documentation](https://duckdb.org/docs/). Base de datos analítica embebida.
2. **DuckDB.** [CSV Import](https://duckdb.org/docs/data/csv/overview). Consultar archivos CSV.
3. **DuckDB.** [Why DuckDB](https://duckdb.org/why_duckdb). Diseño y objetivos del proyecto.
4. **Apache.** [Apache Parquet](https://parquet.apache.org/docs/). Formato de archivo columnar.

## Guías relacionadas

- [Importar un CSV en MySQL y PostgreSQL](../como-importar-un-csv-en-mysql-y-postgresql/index.md)
- [Relacional vs no relacional](../relacional-vs-no-relacional/index.md)
- [Transacciones y ACID](../transacciones-y-acid-en-bases-de-datos/index.md)
- [Qué es una base de datos](../que-es-una-base-de-datos/index.md)
- [Índice de Bases de datos](../index.md)