AWS adquiere DuckLabs

La adquisición de DuckLabs por parte de AWS, la empresa detrás de la popular base de datos analítica de código abierto DuckDB, ha provocado tanto felicitaciones para los fundadores como preocupación por la independencia a largo plazo. Los comentaristas señalan que la propiedad intelectual principal de DuckDB sigue bajo una fundación sin ánimo de lucro y con licencia MIT, pero temen que la influencia de Amazon, su enfoque en productos en la nube y su historial mixto con el código abierto puedan redirigir las prioridades de desarrollo lejos de la analítica ligera y embebida. Muchos esperan integraciones más estrechas con AWS y posible competencia con actores como MotherDuck, Snowflake y Databricks, mientras otros destacan proyectos alternativos (p. ej., Apache DataFusion, SedonaDB) como posibles apuestas de cobertura.

Adquisición y gobernanza

  • AWS está adquiriendo DuckLabs (la empresa de servicios/desarrollo), no DuckDB en sí.
  • DuckDB sigue bajo licencia MIT y su propiedad intelectual está en manos de la fundación sin ánimo de lucro DuckDB Foundation, que gobierna el proyecto.
  • MotherDuck (DuckDB en la nube) es una empresa aparte y dice que la colaboración con DuckLabs/AWS continuará.
  • Algunos señalan que el mensaje anterior de DuckLabs (“independiente, sin VC”) se actualizó discretamente después del acuerdo.

Reacciones de la comunidad

  • Muchos felicitan a los fundadores y se alegran de que probablemente obtuvieron un buen pago.
  • Igual de fuerte es la decepción y la ansiedad: “no podemos tener cosas bonitas” / “RIP al Duck independiente”.
  • Usuarios que dependen de DuckDB para analítica local, visualización de parquet y como sustituto de pandas/Polars se preocupan por su dirección a largo plazo bajo AWS.

AWS, cultura y futuro del proyecto

  • Opiniones divididas sobre AWS:
    • Algunos sostienen que AWS suele mantener vivos los proyectos y señalan esfuerzos previos de código abierto (p. ej., OpenSearch, Firecracker, Valkey).
    • Otros ven a AWS como depredadora o indiferente hacia el trabajo “técnicamente interesante”, esperando reorganizaciones, mucho proceso pesado (MBRs), agotamiento y la eventual pérdida de los desarrolladores principales.
  • Debate sobre si una fundación realmente protege el proyecto una vez que la mayoría de los desarrolladores clave están en nómina de AWS.
  • Temores de funciones de “DuckDB empresarial” que solo existan en AWS, o de una deriva gradual lejos de la visión original de OLAP embebido.

Código abierto, bifurcaciones y alternativas

  • Varios señalan que, al ser software con licencia MIT, DuckDB puede bifurcarse si hace falta; Haybarn y Pygmy-Goose se citan como distribuciones comunitarias ya existentes.
  • Se hacen comparaciones con Redis, Elastic, MySQL, Java, Terraform, Docker, etc., con resultados mixtos tras el control corporativo.
  • Alternativas sugeridas o comentadas: Apache DataFusion (especialmente en ecosistemas Rust), ClickHouse, Postgres, SedonaDB para geoespacial, y simplemente seguir con SQLite.

Dirección técnica y casos de uso

  • A algunos ya les preocupaban funciones de DuckDB 2.0 como el modo servidor y la E/S asíncrona, viéndolas como movimientos hacia la nube/productización.
  • Otros están entusiasmados con próximos índices más grandes que la memoria, vistas materializadas en tiempo real, integraciones tipo DuckLake/S3 y casos de uso de IA/búsqueda vectorial.
  • Un hilo lateral explica por qué existen tantas bases de datos distintas: diferentes compromisos para OLTP frente a OLAP, escala, latencia y patrones de consulta.

Economía y “riqueza generacional”

  • Larguísimo debate sobre qué constituye “riqueza generacional” (cifras desde ~1 millón de dólares hasta varios millones por hijo).
  • Hay consenso en que los fundadores probablemente salieron muy bien; la mayoría de los empleados probablemente recibirá pagos modestos, no que cambien la vida.
  • Frustración más amplia por la consolidación de infraestructura clave bajo unos pocos gigantes tecnológicos y el desequilibrio de poder resultante.