DuckDB 1.5.3 en pymes: CSV, Parquet y control
Guía técnica 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 reunión: una planilla abre, otra redondea y nadie sabe que versión alimenta el número. DuckDB 1.5.3, publicado el 20 de mayo, permite consultar CSV y Parquet desde archivos locales. Esta guía explica donde vive cada dato, quien ejecuta consultas y como repetir la salida.
Dónde 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 qué permite fijar versión 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 más 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 también necesitan versión, permiso, salida y restauración.
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 número llega desde varios lugares y debe quedar escrito una sola vez para poder revisarlo. La documentación estable de DuckDB describe una base analitica embebida. La guía de Parquet explica lectura y escritura de archivos columnares. La guía 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.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, cada área 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, versión de consulta y estado de aprobación. 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 auditoría de corridas. MinIO/S3 recibe archivos pesados y entrega objetos con fecha, hash y versión. El permiso separa carga, ejecución, lectura y aprobación. 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.
Qué se instala o configura primero
La pila inicial usa DuckDB 1.5.3, carpeta de entrada, SQL versionado, PostgreSQL 18 para auditoría, repositorio S3 o MinIO, usuario de servicio, tablero de corridas, backup diario y restauración mensual. El piloto cuesta entre USD 600 y USD 1.900, entre ARS 847.200 y ARS 2,68 millones al dólar 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, dirección aprueba y un usuario de deposito intenta borrar la salida. El sistema debe rechazarlo o dejar un evento que permita reconstruir quién 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 comparación 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 versión, usuario y hash, el reporte ya tiene una forma de defensa operativa.
Dónde se rompe y cómo probarlo Primer riesgo: columna numerica leida como texto.
La señal 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 señal es un hash distinto para un periodo cerrado. La prueba guarda hash y bloquea reemplazos sin aprobación. Tercer riesgo: permisos de carpeta demasiado amplios. La señal 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 señal es una restauración 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.