DuckDB el josiete.com

DBeaver: la navaja suiza del data engineer

Thu, 24 Sep 2026 00:00:00 +0000

Hay herramientas que resuelven una tarea concreta y otras que terminan convirtiéndose en el cajón de herramientas entero. DBeaver pertenece a la segunda categoría: es un cliente de bases de datos multiplataforma desde el que podemos conectarnos, consultar, explorar, editar y exportar datos sin cambiar de aplicación. Para un data engineer, se parece bastante a una navaja suiza con una interfaz gráfica.

¿Qué es DBeaver?

DBeaver es una aplicación de escritorio para trabajar con bases de datos y otras fuentes de datos. Permite abrir conexiones JDBC, navegar por esquemas y tablas, escribir SQL con autocompletado, inspeccionar planes de ejecución, editar registros y gestionar metadatos.

Su gran ventaja es reunir en un mismo espacio tareas que normalmente repartiríamos entre la consola, el IDE, una hoja de cálculo y varias herramientas del proveedor. Desde el navegador de metadatos podemos entender rápidamente qué contiene una base de datos; desde el editor SQL podemos probar una consulta; y desde los resultados podemos filtrar, ordenar, copiar o exportar la información.

DBeaver Community es software libre y existe también una edición Enterprise con funciones adicionales para equipos y fuentes de datos concretas. La empresa que desarrolla el producto es DBeaver Corp, con sede en Estados Unidos. El proyecto nació alrededor de la comunidad open source y la compañía mantiene tanto la edición Community como las variantes comerciales.

Un cliente, muchas bases de datos

DBeaver no es un motor de base de datos: es el cliente que se conecta a ellos. Esa distinción es importante. No sustituye a PostgreSQL, MySQL, SQL Server, Oracle, MariaDB, SQLite o Snowflake; ofrece una experiencia común para trabajar con todos ellos.

Según el controlador y la edición, podemos conectarnos a bases de datos relacionales, almacenes analíticos, servicios cloud y fuentes que exponen un controlador JDBC. También podemos configurar túneles SSH, gestionar credenciales, guardar conexiones y abrir varias sesiones en paralelo. La interfaz no elimina las diferencias entre motores, pero reduce el coste mental de saltar de uno a otro.

Está disponible para Linux, Windows y macOS. En Linux resulta especialmente útil para quien alterna entre servidores, contenedores y un portátil de desarrollo; en Windows encaja bien con los equipos que trabajan con SQL Server, PostgreSQL, servicios cloud y herramientas corporativas. La misma idea y buena parte del flujo de trabajo viajan con nosotros entre sistemas operativos.

Parquet: cuando una tabla no vive en una base de datos

Parquet es un formato de almacenamiento columnar, no una base de datos. Guarda los datos organizados por columnas y conserva metadatos que permiten leer solo las partes necesarias. Por eso es habitual en data lakes y pipelines analíticos: ocupa poco, comprime bien y funciona con muchos motores.

DBeaver puede explorar ficheros Parquet directamente mediante motores y conexiones compatibles, en lugar de obligarnos a cargarlos primero en una base de datos tradicional. Esto resulta útil para inspeccionar un dataset recibido de otro equipo, comprobar los tipos de las columnas, detectar valores nulos o validar una partición antes de construir un pipeline.

Hay que distinguir dos operaciones. Visualizar un Parquet permite conocer su contenido; consultarlo con SQL requiere que haya un motor que lo lea. Ahí entra DuckDB: DBeaver proporciona la interfaz y DuckDB proporciona el motor analítico.

DBeaver y DuckDB: una pareja muy práctica

DuckDB es una base de datos analítica embebida que puede consultar Parquet, CSV y JSON sin levantar un servidor. DBeaver puede conectarse a DuckDB y convertirse en su entorno visual: escribimos SQL en el editor, vemos el plan y los resultados en tablas, y exploramos los objetos con una experiencia familiar.

Una consulta típica puede ser tan sencilla como esta:

SELECT customer_id, sum(amount) AS total
FROM 'data/sales/*.parquet'
GROUP BY customer_id
ORDER BY total DESC
LIMIT 20;

El fichero sigue siendo Parquet y DuckDB lo lee directamente; no hace falta importarlo a una base de datos servidor para empezar a analizarlo. Esta combinación es especialmente cómoda para trabajo exploratorio, controles de calidad y prototipos: DBeaver permite investigar visualmente y DuckDB aporta un SQL rápido y portable.

También sirve para crear una base DuckDB local, unir varios ficheros, materializar resultados intermedios y exportarlos de nuevo. El flujo queda en un punto muy atractivo entre una hoja de cálculo y una plataforma de datos completa.

¿Por qué llamarla “la navaja suiza”?

La metáfora no significa que DBeaver haga todo mejor que una herramienta especializada. Significa que cubre muchas necesidades con una fricción sorprendentemente baja:

explorar esquemas, índices, vistas y permisos;
escribir y guardar consultas SQL;
comparar resultados y revisar planes de ejecución;
editar datos puntuales con cuidado;
importar y exportar CSV, JSON y otros formatos;
trabajar con varias conexiones y pestañas;
documentar consultas y compartir configuraciones con el equipo;
conectarse a motores clásicos, servicios cloud y bases embebidas.

Para una persona que está aprendiendo SQL, la vista de datos ofrece feedback inmediato. Para un perfil experimentado, el valor está en tener contexto, consultas y resultados en el mismo lugar. Y para el data engineer, la mezcla de conexiones heterogéneas, Parquet y DuckDB reduce mucho el tiempo entre “me han pasado estos ficheros” y “ya sé qué contienen”.

Lo que conviene tener en cuenta

La comodidad no elimina la responsabilidad. Una conexión de producción debe protegerse con credenciales adecuadas, permisos mínimos y cuidado al ejecutar UPDATE, DELETE o migraciones. También conviene recordar que una interfaz gráfica puede ocultar diferencias de dialecto, costes de consulta y políticas de acceso.

DBeaver tampoco es un orquestador ni un sistema de gobierno del dato. No reemplaza un pipeline versionado, las pruebas automáticas, el control de cambios o la observabilidad. Su papel es más concreto y, precisamente por eso, muy valioso: ser una estación de trabajo flexible para entender y operar sobre datos.

Una herramienta pequeña para problemas variados

La mejor forma de entender DBeaver es usarlo como una capa de trabajo común. Un día puede ser el cliente de PostgreSQL; al siguiente, la ventana desde la que inspeccionamos un Parquet con DuckDB; después, un explorador de una base SQLite local o una consola para un almacén analítico.

Esa versatilidad explica su popularidad. DBeaver no intenta decidir dónde deben vivir los datos: nos ayuda a verlos, preguntarles cosas y movernos entre sistemas. Y cuando el castor del logo aparece junto a un fichero Parquet y una consulta DuckDB, la broma deja de ser solo visual: representa bastante bien una forma moderna y pragmática de trabajar con datos.

DuckDB: el pato analítico que acaba de aterrizar en AWS

Wed, 23 Sep 2026 00:00:00 +0000

Hay herramientas que aparecen en los pipelines de datos porque una gran empresa las impone y otras que se extienden porque resuelven un problema cotidiano con una elegancia difícil de ignorar. DuckDB pertenece a la segunda categoría. Es una base de datos analítica embebida, pequeña, rápida y capaz de consultar archivos locales o remotos con SQL. En los últimos años se ha convertido en una pieza habitual del trabajo de Data Engineering, Data Science y Analytics Engineering.

Y ahora está en el centro de una noticia importante: Amazon ha incorporado DuckLabs a AWS, la empresa de Ámsterdam creada alrededor del equipo que desarrolla DuckDB. La operación se anunció en agosto de 2026 y DuckLabs confirmó que se completó el 31 de agosto. La parte importante para los usuarios es que no se ha comprado el proyecto open source: DuckDB continúa bajo la tutela independiente de la DuckDB Foundation y bajo licencia MIT.

¿Qué es DuckDB?

DuckDB es un sistema gestor de bases de datos relacional orientado a análisis —OLAP—. A diferencia de una base de datos servidor tradicional, se ejecuta dentro del proceso de la aplicación: se importa como una librería de Python, R, Go, Java, Rust, Node.js o C++, o se usa desde su CLI.

SELECT country, sum(amount) AS total
FROM 'sales/*.parquet'
GROUP BY country
ORDER BY total DESC;

No hace falta levantar un clúster ni crear primero una tabla intermedia. DuckDB puede consultar directamente CSV, Parquet, JSON y otros formatos, incluidos datos accesibles mediante HTTP(S) o S3. Su motor vectorizado procesa lotes de valores en cada operación y está optimizado para escanear, filtrar, agregar y combinar cantidades grandes de datos.

La comparación que mejor lo explica es con SQLite: ambos son sencillos, embebidos y portables, pero SQLite está pensado principalmente para cargas transaccionales y DuckDB para consultas analíticas. No es un sustituto universal de PostgreSQL, una cola de eventos o un warehouse distribuido. Su virtud es ocupar un lugar muy concreto y hacerlo extraordinariamente bien.

¿Quién lo mantiene?

DuckDB nació en el grupo de arquitecturas de bases de datos de CWI Amsterdam, con Hannes Mühleisen y Mark Raasveldt entre sus creadores. El desarrollo profesional se organizó en DuckDB Labs, que posteriormente pasó a llamarse DuckLabs.

La pieza de gobernanza clave es la DuckDB Foundation, una fundación neerlandesa sin ánimo de lucro que posee la propiedad intelectual y las marcas del Duck Stack. Su consejo incluye a los creadores de DuckDB y a Peter Boncz, investigador de sistemas de bases de datos. DuckLabs aporta el equipo de ingeniería; la Foundation protege el proyecto y su licencia abierta.

¿Por qué es software libre?

DuckDB se distribuye bajo la licencia MIT, una licencia permisiva que permite usar, estudiar, modificar y redistribuir el software, también dentro de productos comerciales. La propia documentación de DuckDB explica que el proyecto nació en un entorno de investigación pública neerlandesa y que sus autores consideran una responsabilidad social hacer accesibles sus resultados.

La libertad no es solo una cuestión moral o académica. En una herramienta que se coloca en medio de un pipeline, poder inspeccionar el motor, compilarlo para distintas arquitecturas y añadir extensiones reduce el riesgo de dependencia. También permite que universidades, empresas, fabricantes de herramientas y usuarios individuales trabajen sobre la misma base.

¿Por qué se ha puesto tan de moda en Data Engineering?

La popularidad de DuckDB no se explica por una única característica, sino por cómo encajan varias:

Cero infraestructura para empezar: se instala como una librería y no exige administrar servidores.
SQL sobre archivos: convierte un directorio de Parquet o CSV en una fuente consultable sin cargarlo antes en un sistema central.
Velocidad analítica: su ejecución columnar y vectorizada encaja con agregaciones, joins y escaneos completos.
Portabilidad: funciona en un portátil, un contenedor, una función, un navegador mediante WebAssembly o un servidor grande.
Encaje con Python y R: permite pasar de un DataFrame a SQL y volver sin mover innecesariamente los datos.
Interoperabilidad: Parquet, JSON, HTTP(S), S3, extensiones y formatos de lakehouse forman parte de su ecosistema.
Reproducibilidad: un fichero de base de datos o un script SQL puede acompañar al proyecto y ejecutarse en CI, en local o en un notebook.

Esto cambia el orden tradicional de algunos flujos. En vez de subir todos los datos a un warehouse para empezar a explorar, un ingeniero puede hacer una primera transformación local sobre los objetos del lake, validar una hipótesis y materializar solo lo que merece convertirse en un proceso permanente. DuckDB no elimina el warehouse: hace más barato y rápido el trabajo que ocurre antes, al lado o entre sus consultas.

La adquisición de Amazon: qué ha pasado realmente

Conviene ser preciso con los términos. AWS ha adquirido DuckLabs, no el proyecto DuckDB como si fuera una aplicación cerrada. Según Amazon, Hannes Mühleisen y Mark Raasveldt seguirán liderando el equipo y la dirección técnica del proyecto. Según el anuncio de DuckLabs, el equipo permanece unido en Ámsterdam, DuckDB, DuckLake y Quack continúan bajo la Foundation y el software sigue bajo MIT.

El interés de AWS es comprensible: DuckDB es una capa muy eficaz para trabajar cerca de los datos, especialmente en S3, y puede conectar ficheros, notebooks, aplicaciones, lakehouses y servicios analíticos. La combinación da a AWS acceso a talento especializado y al proyecto le da recursos, infraestructura y una distribución comercial mucho mayores.

¿Cambiará el diseño de DuckDB?

Todavía es pronto para afirmar qué decisiones concretas cambiarán. Los anuncios públicos dicen que no cambian la licencia, la gobernanza ni la hoja de ruta inmediata. Lo que sí podemos hacer es plantear hipótesis razonables:

Más profundidad en el ecosistema cloud. Es probable que veamos más trabajo en S3, formatos de lakehouse, catálogos, permisos y conexiones con servicios de AWS. El reto será mejorar esa integración sin convertir DuckDB en un cliente privilegiado de un solo proveedor.
Más inversión en funcionamiento remoto. DuckDB nació como motor embebido, pero su ecosistema ya explora protocolos y escenarios distribuidos. AWS puede acelerar características que permitan pasar de la exploración local a datos remotos sin perder la sencillez del modelo.
Mayor presión sobre extensiones y compatibilidad. La Foundation y DuckLabs han indicado que quieren ampliar la comunidad y el sistema de extensiones. Eso puede traer más conectores y formatos, pero también exige mantener APIs estables, seguridad y una experiencia coherente.
Diseño vendor-neutral como decisión estratégica. Paradójicamente, para que AWS obtenga valor a largo plazo, DuckDB debe seguir siendo útil fuera de AWS. La adopción que lo hizo valioso depende de que funcione en local, en otras nubes, en notebooks y dentro de productos de terceros.

Estas son inferencias, no compromisos publicados. La prueba será observar si las nuevas integraciones se diseñan como extensiones abiertas y si la comunidad conserva capacidad real para discutir la hoja de ruta. La Foundation ya ha anunciado un consejo asesor técnico con participación de la comunidad, algo que puede ayudar a convertir esa apertura en práctica de diseño.

La pregunta interesante

La compra no responde solo a si Amazon puede sacar provecho de DuckDB. La pregunta más interesante es si una empresa cloud puede financiar un componente de infraestructura que siga siendo neutral, pequeño y agradable de usar, incluso cuando ese componente haga más sencillo trabajar fuera de su propia nube.

Por ahora, la respuesta oficial es tranquilizadora: DuckDB sigue siendo libre, la licencia MIT permanece y la Foundation conserva la tutela del proyecto. El futuro dependerá de las decisiones menos visibles: qué se prioriza, qué se mantiene fuera del núcleo, cómo se aceptan extensiones, cómo se cuida la portabilidad y quién tiene voz cuando hay un conflicto entre la comunidad y los intereses de AWS.

DuckDB se puso de moda porque redujo la distancia entre una pregunta y una respuesta sobre datos. Su siguiente etapa será interesante si consigue reducir también la distancia entre el mundo local y la nube sin obligarnos a escoger una sola de las dos cosas.