DuckLabs pasará a ser una subsidiaria de AWS y DuckDB seguirá siendo MIT bajo una fundación independiente. Esa fundación tiene un board de tres asientos, dos son de las personas que se van a AWS, y el board se nombra a sí mismo. Esa es la historia completa, y casi nadie la está contando.
Estado al 27 de agosto de 2026: la operación no está cerrada. Amazon dice que el acuerdo está sujeto a “customary closing conditions” y que espera cerrar “pronto”, sin fecha. El post de los fundadores habla de principios de septiembre. Cualquier frase en pasado sobre esta adquisición, hoy, es incorrecta.
El 26 de agosto Mark Raasveldt y Hannes Mühleisen firmaron un post en duckdb.org anunciando que DuckLabs —la empresa de Ámsterdam que construyeron alrededor de DuckDB, hoy más de 30 personas— se suma a Amazon Web Services. El comunicado de Amazon es cuidadoso de una manera que merece crédito: “We are not acquiring the DuckDB open source project, which will remain free and open source under the independent DuckDB Foundation… and available under the MIT license as it does today.” Andy Warfield, el VP de Amazon citado en él, no está exagerando nada. No se revelaron términos financieros.
Quiero ser preciso con lo que estoy y no estoy argumentando. No estoy diciendo que AWS esté por cambiarle la licencia a DuckDB. No puede, y dijo que no lo hará. Estoy diciendo que la frase que todo el mundo está repitiendo —la fundación se queda la licencia, así que no cambia nada— está cargando mucho más peso del que puede sostener, y que el documento que decide cuánto peso puede sostener es público, tiene tres páginas, y parece que nadie lo leyó.
¿Qué protege realmente la licencia MIT?
Protege el código que ya existe. Cada línea publicada bajo MIT queda publicada bajo MIT, para siempre, para cualquiera: eso es irrevocable, y por eso el comentario más votado en Hacker News (1.066 puntos y 308 comentarios al momento de escribir esto) es el correcto: “AWS acquired DuckLabs, NOT DuckDB. The DuckDB source code is still owned by the nonprofit DuckDB Foundation.”
Esa protección es real y no es poca cosa. Si todo sale mal, la comunidad hace fork desde el último commit MIT y sigue. Esa salida existe.
Lo que MIT no protege es todo aquello sobre lo que de verdad planificas: qué features se construyen, en qué orden y con qué prioridades; qué extensiones se mantienen; si el formato de almacenamiento evoluciona hacia S3 e Iceberg o se mantiene neutral; con qué velocidad se atiende tu bug. Las licencias gobiernan copias. Los roadmaps gobiernan valor, y los roadmaps los gobiernan personas. Ashish Chaturvedi, de HFS Research, lo dijo a InfoWorld más directo de lo que yo lo diría: “Developers shouldn’t mistake an unchanged license for an unchanged project. The people writing the bulk of DuckDB’s core code now cash AWS paychecks, and paychecks bend roadmaps.”
Y un fork tampoco es un plan. Es un procedimiento de recuperación ante desastres, y como todo procedimiento de ese tipo, su costo se mide en gente que tendrías que contratar.
¿Qué es DuckDB y en qué se diferencia de SQLite?
Vale la pena definir el sujeto, porque de esa diferencia depende buena parte de tu exposición.
DuckDB es una base de datos analítica embebida: corre dentro de tu proceso, sin servidor que administrar, igual que SQLite. La diferencia está en para qué está construida cada una. SQLite es transaccional y orientada a filas: está pensada para leer y escribir registros individuales, que es lo que hace una aplicación. DuckDB es columnar y vectorizada: está pensada para barrer millones de filas y agregarlas, que es lo que hace una consulta analítica.
En la práctica esto significa que no compiten tanto como parece. SQLite guarda el estado de tu aplicación; DuckDB responde preguntas sobre tus datos —consultando Parquet, CSV o tablas Iceberg directamente— sin que tengas que levantar un data warehouse. Junto a DuckDB, el mismo equipo mantiene DuckLake (formato de lakehouse) y Quack, y todo eso es lo que el anuncio llama el “Duck Stack”.
Ese detalle importa para lo que sigue: la parte embebida y la parte de lakehouse tienen exposiciones muy distintas frente a un dueño estratégico que ya tiene S3 Tables e Iceberg en el portafolio.
¿Quién gobierna la DuckDB Foundation?
Acá está la parte que no vi cubierta en ningún lado, en ningún idioma.
La página de la fundación dice que es una organización sin fines de lucro independiente y que “the foundation holds much of the intellectual property (IP) of the project”. Lista tres miembros del board: Hannes Mühleisen, Mark Raasveldt y Peter Boncz. Se financia con donaciones, con membresía Silver desde 10.000 € y Gold desde 100.000 €; los supporters Gold listados son Voltron Data, MotherDuck y Posit, con Cloudflare como sponsor técnico.
El acta de constitución de la Stichting DuckDB Foundation está publicada como PDF en duckdb.org, y resuelve la pregunta. Su propósito declarado es “to promote the continuity of the DuckDB software, by making and keeping the software generally accessible and available” y administrar los derechos de propiedad intelectual sobre el código y la arquitectura. Después vienen las cláusulas de gobernanza:
- El board se nombra a sí mismo. “Board members shall be appointed, suspended and dismissed by the Board.” No hay socios, no hay electorado, no hay asientos por sponsor. La membresía Gold compra un logo, no un voto. Si el board llegara a quedar vacío por completo, CWI INCUBATOR B.V. puede nombrar a un miembro.
- Los asientos son indefinidos y el board define su propio tamaño. Arrancó en tres; no hay mandatos ni renovación.
- El board puede reescribir sus propios estatutos. “The Board is authorised to amend the Articles of Association”, con todos los miembros presentes o representados.
- Remover a un miembro requiere a todos los demás. Un miembro cesa por “resignation granted by the Board pursuant to a resolution adopted by all other Board members.”
- El único mecanismo frente a conflictos es por decisión puntual. “A Board member shall not participate in the deliberations and decision-making if he has a direct or indirect personal interest in doing so that conflicts with the interests of the Foundation.” Eso es una regla de abstención, no una regla estructural, y cada miembro la evalúa por sí mismo.
Ahora cuenta. Dos de los tres asientos pertenecen a los fundadores que van a dirigir DuckLabs dentro de AWS desde septiembre. Nada en los anuncios dice que alguno de ellos vaya a dejar el board, y nada en el acta lo exige: no hay ninguna cláusula sobre empleo, afiliación o neutralidad de proveedor en todo el documento. Así que la institución que tiene el IP, y que puede modificar su propia carta orgánica, muy probablemente quede con una mayoría de dos tercios empleada por el comprador.
No lo leo como una maniobra. Esta estructura se armó en 2021 para un spin-off de investigación, y para eso era apropiada. Simplemente no fue diseñada para aguantar a un hyperscaler, y ahora se la está citando como si lo estuviera.
El remedio anunciado tampoco lo resuelve, y los dos anuncios ni siquiera lo describen igual: duckdb.org habla de un advisory board de stakeholders, mientras que ducklabs.com dice “technical advisory board, so that leading community members can provide their input on the project’s technical direction”. Las dos palabras importan. Input no es voto, y un board consultivo que no figura en los estatutos puede ser disuelto por el órgano al que asesora.
¿Qué pasó con OpenSearch y Elasticsearch?
Es la pregunta obligada, porque es el único precedente donde AWS es el protagonista. Y la respuesta es mejor que la reputación de la empresa, con un asterisco sobre los plazos.
En 2021 Elastic cambió Elasticsearch a la licencia SSPL. AWS hizo un fork y lo llamó OpenSearch, manteniéndolo bajo Apache 2.0. Y el 17 de septiembre de 2024 transfirió el proyecto a la Linux Foundation como OpenSearch Software Foundation, con un comité directivo técnico y un board de gobierno con clases de miembros: AWS, SAP y Uber como premier, junto a miembros generales que incluyen a Aiven, Atlassian, Canonical, DigitalOcean, Graylog e Instaclustr. La página de principios del proyecto se compromete por escrito a que “we will not tweak the software so that it runs better for any vendor (including AWS) at the expense of others”. No hay CLA.
Eso es una cesión de control real y documentada por parte de AWS, y quien argumente que la empresa es estructuralmente incapaz de hacerlo tiene que explicar OpenSearch.
Pero mira la forma. Tardó tres años, y le ocurrió a un proyecto que AWS había creado y controlaba por completo, bajo presión competitiva de un fork que ella misma había hecho. Lo que significa que el precedente de OpenSearch no es una garantía de que la gobernanza de DuckDB esté bien hoy. Es la descripción del destino —un board multi-proveedor con clases de miembros definidas y compromisos de neutralidad por escrito— y una medición de cuánto tardó el viaje la vez anterior.
La distancia entre un board de gobierno de la Linux Foundation y tres asientos autodesignados no es un detalle. Es exactamente la distancia entre la promesa que se está haciendo y la estructura que la respalda.
¿Qué haría yo ahora?
Nada de esto justifica arrancar DuckDB de ningún lado. Es MIT, es embebido, no tiene servidor del que te puedan desconectar, y el código que tienes hoy es tuyo para siempre. Esa es una posición genuinamente sólida —bastante más sólida que la que tuvo cualquiera cuando Elastic o Redis cambiaron términos, porque acá no hay licencia que te puedan cambiar por debajo.
Lo que sí justifica es decidir, deliberadamente y este mes, cuánto de tu arquitectura depende de decisiones que ahora toman personas que trabajan para un solo proveedor de nube.
- Fija tu versión y anota cuál es. MIT protege el commit que tienes. Esa protección solo es real si sabes cuál es ese commit y puedes compilar desde ahí.
- Separa DuckDB de DuckLake en tu registro de riesgos. El motor embebido y el formato de lakehouse tienen exposiciones muy distintas frente a un dueño con Iceberg y S3 Tables en el portafolio. Trátalos como dos decisiones.
- Inventaria tus extensiones por mantenedor. El core es la parte más segura de todo esto. Las extensiones con un único mantenedor corporativo son donde un roadmap desviado se nota primero.
- Pregunta, por escrito, si los fundadores siguen en el board de la fundación después del cierre. Es una pregunta justa, respondible, no cuesta nada hacerla, y la respuesta te dice más que los tres anuncios juntos.
- Observa en qué se convierte el advisory board, no que lo hayan anunciado. La señal que hay que buscar es una modificación de los estatutos que cree asientos que AWS no controle. Si dentro de doce meses el advisory board existe pero el board estatutario sigue teniendo tres asientos, ya tienes tu respuesta.
- Calcula el costo de tu fork una vez, y después deja de pensar en eso. No para ejecutarlo: para saber el número. Para la mayoría de los equipos es chico, y saber que es chico es lo que te permite adoptar con tranquilidad en vez de cubrirte de forma cara.
El resultado más probable acá es bueno: un equipo bien financiado entregando más rápido bajo una licencia permisiva, exactamente como se prometió. Yo simplemente prefiero sostener esa expectativa porque revisé la estructura y no porque un comunicado me haya dicho que la fundación es independiente.
¿Tienes DuckDB en producción hoy? Me interesa sobre todo si lo estás usando embebido dentro de una aplicación o como capa de consulta sobre un lakehouse, porque la exposición a esta operación no es la misma en los dos casos.