El 26 de agosto, Mark Raasveldt y Hannes Mühleisen publicaron una nota muy breve en el blog de DuckDB: DuckLabs, la empresa detrás de DuckDB, pasa a ser una filial de Amazon Web Services. La operación se cierra a principios de septiembre.
Lo he leído con más atención de la habitual porque en CARTO llevamos relativamente poco tiempo usando DuckDB, y yo mismo he escrito aquí sobre formatos de archivo y rendimiento y sobre el lío de httpfs detrás de un proxy. Cuando adoptas una pieza en producción y meses después la compra un hiperescalador, lo mínimo es sentarse a mirar la letra pequeña.
Lo que dice el anuncio
Es corto, así que conviene separar bien las dos entidades que hay en juego, porque el titular las confunde con facilidad.
DuckLabs es la empresa. Es lo que compra AWS.
DuckDB es el proyecto de software libre. Lo custodia la DuckDB Foundation, una fundación sin ánimo de lucro, y no forma parte de la operación.
Sobre esa separación, el anuncio se moja en cuatro puntos concretos:
| Compromiso | |
|---|---|
| Licencia | MIT, sin cambios |
| Gobernanza | Sigue bajo la DuckDB Foundation |
| Roadmap | Sin cambios |
| Alcance | DuckDB, DuckLake, Quack y el resto de extensiones |
Y dos novedades que no son solo continuidad: la Fundación creará un consejo asesor de stakeholders que podrá influir en la dirección de los proyectos, y se levantan las limitaciones del soporte comunitario.
Ese segundo punto es el que más me interesa, y volveré sobre él.
Por qué la estructura importa aquí
Que el proyecto viva en una fundación separada de la empresa no es un detalle burocrático. Es exactamente la diferencia entre esta noticia y otras que hemos vivido peor.
Cuando una empresa es dueña del copyright de su propio proyecto libre, puede relicenciarlo. Lo hemos visto varias veces en la última década: un cambio a una licencia no-OSI, la comunidad reacciona, aparece un fork, y quienes lo tenían en producción se pasan seis meses decidiendo qué rama seguir. Redis, Elasticsearch, Terraform, HashiCorp en general. El patrón se repite.
Aquí la propiedad ya estaba fuera de la empresa antes de la compra. AWS adquiere DuckLabs —el equipo, el negocio, el soporte comercial— pero no adquiere la capacidad de relicenciar DuckDB, porque esa capacidad no era de DuckLabs. La Fundación existe desde hace años precisamente para esto.
Dicho de otra forma: la protección no la da la promesa del anuncio, la da la estructura legal que ya existía. Y esa es una distinción importante, porque las promesas de continuidad tras una adquisición son baratas y todos hemos visto unas cuantas evaporarse.
Lo que sí cambia
Sería ingenuo leer esto como “no cambia nada”. Cambian cosas, solo que no son las que asustan en el titular.
El soporte deja de estar limitado. Esto es dinero de AWS financiando algo que hasta ahora tenía que racionarse. Para quien usa DuckDB en producción es probablemente la mejor noticia del anuncio, y es puramente positiva.
La integración con el ecosistema AWS va a acelerar. Es la razón económica evidente de la compra. Cabe esperar mejor soporte de S3, de Iceberg, del catálogo de Glue. Nada de eso perjudica a quien no usa AWS, pero sí marca dónde se va a concentrar el esfuerzo.
El sesgo del roadmap. Aquí es donde pondría yo la atención a medio plazo. El roadmap no cambia hoy, pero el equipo que lo decide ahora cobra de AWS. Cuando haya que priorizar entre una mejora que beneficia a S3 y otra que beneficia a Azure Blob, la presión no será explícita: será una cuestión de a quién tiene uno delante cada día. El consejo asesor de stakeholders parece pensado justamente para contrapesar eso, y su composición dirá bastante más que cualquier comunicado.
Cómo lo veo desde nuestro caso
En CARTO usamos DuckDB en una parte concreta —ingesta y procesamiento de datos—, no como el motor central de la plataforma. Esa posición hace que la noticia sea bastante más tranquila de lo que sería en otro escenario.
Y creo que ahí está la lección práctica que se puede sacar, más allá de esta adquisición concreta: lo que determina tu exposición no es quién compra a quién, sino cuánto has acoplado tu arquitectura a esa pieza.
Si DuckDB es una herramienta que usas para leer Parquet, transformar y escribir, tu coste de sustitución es real pero acotado. Si has construido encima suyo con extensiones propias, funciones específicas y dependencias de su comportamiento exacto, entonces cualquier cambio de rumbo del proyecto es un problema tuyo. La adquisición no altera esa ecuación, solo hace que valga la pena mirarla.
Es la misma reflexión que hacía hace unos días sobre conectar con data warehouses ajenos: la parte que controlas es pequeña, y conviene saber exactamente dónde termina.
Mi lectura
Soy moderadamente optimista, con una reserva.
El optimismo viene de la estructura. La Fundación, la licencia MIT y el hecho de que la propiedad ya estuviera separada del negocio son garantías reales, no declaraciones de intenciones. Añade a eso que los fundadores siguen dirigiendo la parte técnica y que el proyecto tiene una comunidad grande —pasó los 40.000 estrellas en GitHub este mismo mes— y el escenario catastrófico es poco probable.
La reserva es más difusa y no tiene que ver con las cláusulas. Un proyecto financiado por un hiperescalador tiende, con el tiempo, a parecerse a lo que ese hiperescalador necesita. No por mala fe, sino por gravedad: es donde están los usuarios que pagan, los casos que se reportan y las prioridades que llegan cada mañana. DuckDB nació como una base de datos analítica embebida que corre en cualquier sitio, y ese “cualquier sitio” es buena parte de su gracia.
Por ahora, nada que hacer más allá de seguir usándolo. La adopción en CARTO continúa igual, y estos dos anuncios —el consejo asesor y quién acaba sentándose en él— son lo que merece la pena vigilar en los próximos meses.
