Ejecutar una base de datos DuckDB completa directamente en S3 sin servicios adicionales

Los ingenieros han desarrollado un método para ejecutar una base de datos DuckDB completa directamente en almacenamiento de objetos como Amazon S3, eliminando la necesidad de servidores de bases de datos separados o catálogos complejos de lagos de datos. Publicado en octubre de 2026, este enfoque utiliza una extensión personalizada llamada duckdb_objfs para mapear el motor de almacenamiento interno de DuckDB a SlateDB, un almacén clave-valor incrustado diseñado para objetos en la nube.

Qué ha ocurrido

La innovación central es una extensión de DuckDB que permite a la base de datos tratar un bucket de S3 como su disco principal. A diferencia de soluciones existentes como Iceberg o DuckLake, que se centran en compartir tablas Parquet entre diferentes motores, este método preserva el conjunto completo de funciones de DuckDB. Esto incluye índices avanzados, restricciones, vistas, macros y tipos de datos específicos que a menudo se pierden o se mapean incorrectamente al convertirlos a formatos de tabla abiertos.

El sistema permite que un único proceso de escritura actualice la base de datos mientras múltiples procesos adicionales se conectan a los mismos datos en modo solo lectura. Estos lectores pueden ejecutar consultas SQL complejas, incluidas uniones (joins) y agregaciones, directamente contra los datos en el bucket. La arquitectura garantiza que los lectores siempre vean un estado consistente de la base de datos, incluso si están ligeramente por detrás de la última escritura, evitando lecturas parciales o corruptas durante las actualizaciones.

Cómo funciona

La extensión funciona reemplazando la capa de disco subyacente en lugar de modificar el propio motor de almacenamiento de DuckDB. Registra un manejador personalizado del sistema de archivos para el esquema duckdb_objfs://. Cuando DuckDB intenta leer o escribir archivos, la solicitud se reenvía a través de una interfaz C a un núcleo Rust que gestiona SlateDB. SlateDB actúa como un adaptador, traduciendo las operaciones de archivo en llamadas de almacenamiento de objetos utilizando Apache OpenDAL, que soporta varios backends como S3, MinIO y directorios locales.

Para manejar la discrepancia entre las actualizaciones in situ de los archivos de DuckDB y la naturaleza inmutable del almacenamiento de objetos, el sistema alinea los fragmentos de datos con precisión. Cada bloque de 256 KiB de DuckDB se asigna a un único fragmento de 256 KiB en SlateDB, comenzando después de una cabecera de 12 KiB. Esta geometría asegura que escribir un bloque requiera solo una operación put, y leerlo requiera una operación get, evitando ciclos costosos de lectura-modificación-escritura. La durabilidad se mantiene agrupando los fragmentos sucios y los metadatos en un único lote de escritura que se vacía en el bucket antes de que la llamada de sincronización del archivo regrese.

Detalles clave

• Soporte SQL completo: La solución retiene todas las funciones de DuckDB, incluidos los índices ART, los R-trees espaciales y los índices vectoriales HNSW experimentales, que no son compatibles con los formatos de tabla estándar basados en Parquet.
• Modelo de escritor único: Solo un proceso puede escribir en la base de datos a la vez. El aislamiento del escritor (writer fencing) previene conflictos asegurando que los escritores más antiguos reciban errores de E/S si un escritor más nuevo toma el control.
• Lecturas consistentes: Las conexiones de solo lectura utilizan lectores sin aislamiento que actualizan su vista del manifiesto cada diez segundos, garantizando la consistencia sin bloquear al escritor.
• Métricas de rendimiento: En un Apple M4, las lecturas frías desde S3 son aproximadamente 1,2 veces más lentas que HTTPFS nativo, mientras que las escrituras locales son aproximadamente 0,19 veces la velocidad de las escrituras nativas en disco local debido a la latencia de red.
• Sin servicios adicionales: El despliegue requiere únicamente un bucket de S3. SlateDB gestiona la coordinación, la compactación y la recolección de basura dentro del proceso de escritura, eliminando la necesidad de servicios externos de catálogo.
• Integración con Duckherder: Esta capa de almacenamiento sirve como fundamento para Duckherder, un motor de ejecución distribuido que permite a múltiples trabajadores leer datos particionados del mismo bucket para el procesamiento paralelo de consultas.

Por qué importa

Para los ingenieros de software y los equipos de datos, este enfoque simplifica la infraestructura al eliminar la carga operativa de gestionar servidores de bases de datos, copias de seguridad y clústeres de alta disponibilidad. El bucket se convierte en la única fuente de verdad, reduciendo el número de componentes que necesitan aprovisionamiento, seguridad y monitorización. Esto es particularmente valioso para aplicaciones autoalojadas o pequeños equipos que desean el poder de una base de datos relacional sin la complejidad de la administración tradicional de bases de datos.

Sin embargo, las compensaciones involucran latencia y rendimiento de escritura. Dado que cada confirmación (commit) requiere un viaje de ida y vuelta al almacenamiento de objetos, las cargas de trabajo intensivas en escritura serán significativamente más lentas que las operaciones en disco local. Los ingenieros deben diseñar sus aplicaciones para agrupar escrituras pequeñas y aceptar que las réplicas de solo lectura pueden tener un retraso de hasta diez segundos. Este modelo es ideal para cargas de trabajo analíticas donde los datos se añaden o actualizan con poca frecuencia pero se consultan habitualmente por múltiples usuarios o servicios.

Qué puedes hacer

• Evaluar la adecuación de la carga de trabajo: Determina si tu aplicación puede tolerar la latencia de las escrituras en S3 y el retraso de lectura de diez segundos. Este modelo se ajusta mejor a paneles analíticos que a sistemas transaccionales de alta frecuencia.
• Agrupar operaciones de escritura: Agrupa pequeñas actualizaciones en transacciones más grandes para minimizar el número de viajes de ida y vuelta al bucket de almacenamiento de objetos, mejorando el rendimiento general de escritura.
• Usar conexiones de solo lectura: Escala la capacidad de consulta conectando múltiples procesos de solo lectura a la misma base de datos, permitiendo análisis concurrentes sin impactar al escritor.
• Monitorizar estadísticas de E/S: Utiliza las funciones proporcionadas duckdb_objfs_io_stats() y duckdb_objfs_cache_stats() para rastrear conteos de solicitudes, latencia y rendimiento de caché para depuración y optimización.
• Planificar la migración: Dado que el bucket contiene objetos SlateDB en lugar de un archivo .duckdb estándar, usa COPY FROM DATABASE para mover datos hacia dentro y hacia fuera, asegurando la compatibilidad con otras herramientas si es necesario.