DuckDB 1.5.3 en pymes: CSV, Parquet y control
Guia tecnica para usar DuckDB con CSV y Parquet: lectura local, permisos, salida, costo, backup y prueba de repeticion.
El reporte cambia cuando dos CSV tienen la misma columna escrita con tipos distintos. En compras, ventas y stock, esa falla aparece antes de la reunion: una planilla abre, otra redondea y nadie sabe que version alimenta el numero. DuckDB 1.5.3, publicado el 20 de mayo, permite consultar CSV y Parquet desde archivos locales. Esta guia explica donde vive cada dato, quien ejecuta consultas y como repetir la salida.
Donde el CSV grande rompe la planilla
El problema operativo aparece cuando el archivo deja de ser una tabla simple y pasa a ser un insumo mensual. La cifra que corrige la costumbre viene del propio release: DuckDB 1.5.3 se publico el 20 de mayo de 2026 y mantiene binarios descargables para distintos sistemas, lo que permite fijar version en una rutina.
Una consulta repetible vale mas que una planilla abierta a mano.
El dato global muestra por que esa disciplina importa incluso fuera de software. GitHub Octoverse 2025 informo mas de 180 millones de desarrolladores y 630 millones de repositorios. Una concesionaria sobre Ruta 40 en Tunuyan no maneja esa escala, pero sus listas de repuestos, ventas y cobranzas tambien necesitan version, permiso, salida y restauracion.
Que hace DuckDB con archivos que ya existen
El antagonista es la carpeta "reportes finales" con CSV exportados de sistemas distintos y nombres cambiados por WhatsApp. En el sector de compras, una impresora fiscal apagada y una bandeja de facturas impresas dicen lo mismo: el numero llega desde varios lugares y debe quedar escrito una sola vez para poder revisarlo.
La documentacion estable de DuckDB describe una base analitica embebida. La guia de Parquet explica lectura y escritura de archivos columnares. La guia para consultar Parquet muestra consultas directas sobre archivos. El formato columnar de Apache Arrow ayuda a entender por que columnas y tipos reducen trabajo repetido.
Como funciona por dentro
El flujo minimo tiene siete pasos. Primero, cada area deja CSV o Parquet en una carpeta de entrada con nombre de periodo. Segundo, un script valida nombre, fecha, columnas y tipo esperado. Tercero, DuckDB lee los archivos y ejecuta consultas guardadas en SQL. Cuarto, PostgreSQL guarda corrida, responsable, version de consulta y estado de aprobacion. Quinto, DuckDB exporta resultado a Parquet o CSV cerrado. Sexto, MinIO/S3 guarda entrada, salida y logs con metadatos. Septimo, una prueba borra una salida y la reconstruye desde entrada y SQL versionado.
DuckDB recibe archivos y consultas; entrega resultados filtrados, agregados y exportables. PostgreSQL recibe registros estructurados y entrega auditoria de corridas. MinIO/S3 recibe archivos pesados y entrega objetos con fecha, hash y version. El permiso separa carga, ejecucion, lectura y aprobacion. Si falla DuckDB, la salida no se genera. Si falla PostgreSQL, se pierde quien corrio que consulta. Si falla el repositorio, la repeticion queda sin insumos.
Que se instala o configura primero
La pila inicial usa DuckDB 1.5.3, carpeta de entrada, SQL versionado, PostgreSQL 18 para auditoria, repositorio S3 o MinIO, usuario de servicio, tablero de corridas, backup diario y restauracion mensual. El piloto cuesta entre USD 600 y USD 1.900, entre ARS 847.200 y ARS 2,68 millones al dolar vendedor oficial de $1.412 informado por Bluelytics. Incluye tres reportes, dos fuentes, permisos, salida y prueba.
El plazo va de una a tres semanas. UMSA suele pedir un entregable verificable: carpeta de entrada, consulta SQL revisada, salida Parquet, salida CSV, usuario lector, rechazo por permiso incorrecto y reconstruccion en otro equipo. El costo no incluye limpieza historica de datos, licencias de sistemas de origen ni tablero ejecutivo.
La primera prueba toma ventas y stock del mismo mes. Compras carga archivos, el script valida columnas, DuckDB genera margen por familia, direccion aprueba y un usuario de deposito intenta borrar la salida. El sistema debe rechazarlo o dejar un evento que permita reconstruir quien lo hizo.
La segunda prueba cambia un archivo de origen. El resultado debe cambiar solo en las filas afectadas y dejar corrida nueva con hash distinto. Esa comparacion permite discutir el dato antes de discutir el grafico.
La tercera prueba toma el mismo SQL en otro equipo. Si la salida coincide y el log muestra version, usuario y hash, el reporte ya tiene una forma de defensa operativa.
Donde se rompe y como probarlo
Primer riesgo: columna numerica leida como texto. La senal aparece cuando una suma devuelve cero o concatena valores. La prueba revisa tipos antes de ejecutar la consulta. Segundo riesgo: archivo reemplazado con el mismo nombre. La senal es un hash distinto para un periodo cerrado. La prueba guarda hash y bloquea reemplazos sin aprobacion.
Tercer riesgo: permisos de carpeta demasiado amplios. La senal aparece cuando deposito puede borrar salidas aprobadas. La prueba usa un usuario real y exige rechazo. Cuarto riesgo: backup que copia salidas y pierde entradas. La senal es una restauracion que muestra el resultado pero no permite repetirlo. La prueba recupera entrada, SQL y salida en otro host. El reporte mensual vale cuando se puede reconstruir.