DuckDB en pymes: CSV, Parquet y prueba local

¿Qué hacemos con los CSV que gerencia baja cada viernes y nadie puede volver a calcular igual? La pregunta aparece cuando una pyme exporta ventas, cobranzas, stock o tickets para armar un reporte local sin tocar la base de producción. DuckDB entra como motor analítico embebido: lee archivos CSV y Parquet, ejecuta SQL y devuelve resultados en una notebook o script. Esta guía explica dónde vive el dato, quién lo abre y cómo probar la salida.

Dónde aparece el archivo que todos bajan

La encuesta Stack Overflow 2025 reunió más de 49.000 respuestas de 177 países y muestra que SQL sigue dentro de las herramientas habituales de trabajo. Ese dato baja a Mendoza cuando administración ya sabe exportar una planilla, pero cada área calcula margen, mora o stock con una fórmula distinta. DuckDB documenta lectura de CSV y Parquet en su guía estable. La página de CSV cubre detección de formato y carga desde archivos; la de Parquet describe lectura directa de columnas. El punto operativo es chico y pesado a la vez: el archivo que salió del ERP debe conservar fecha, origen, filtro, responsable y versión del cálculo. El antagonista es el adjunto reenviado con el nombre final-final, porque mezcla dato, criterio y resultado en una misma carpeta. Una planilla sin origen puede cerrar una reunión y abrir tres reclamos. La primera tarea es nombrar qué reporte merece ser repetible: cobranzas por zona, ventas por vendedor, compras pendientes o tiempos de soporte. Si la pregunta cambia cada semana, DuckDB ayuda a explorar. Si la pregunta queda fija, el equipo debe guardar consulta, entrada y salida.

Cómo funciona por dentro

El flujo mínimo tiene seis pasos. Primero, el sistema principal exporta un CSV o Parquet con columnas aprobadas: identificador, fecha, estado, importe y dimensión necesaria. Segundo, el archivo queda en una carpeta con permisos o en un bucket S3 compatible, con nombre que incluye fecha y fuente. Tercero, DuckDB lee el archivo desde un script SQL o Python y crea una vista local para consultar. Cuarto, el analista ejecuta una consulta versionada y genera un resultado en CSV, Parquet o HTML. Quinto, gerencia recibe el tablero o tabla con fecha de corte y fuente. Sexto, el backup copia archivo de entrada, consulta, salida y bitácora; una prueba restaura todo en otra máquina y repite el mismo número. DuckDB recibe archivos, tablas o DataFrames y entrega resultados SQL dentro del mismo proceso. CSV guarda filas legibles y fáciles de auditar. Parquet guarda columnas comprimidas, más cómodo para lecturas grandes. Python toma la consulta y entrega scripts reproducibles. La base operativa conserva facturas, pagos, usuarios y auditoría; DuckDB trabaja sobre copias controladas para análisis. Los permisos son simples y exigentes. Administración puede exportar. El analista puede leer el archivo aprobado. Gerencia puede leer la salida. IT puede revisar scripts, rutas y logs. El borrado se maneja por retención: archivos de entrada por 90 días, salidas por 180 o lo que defina la política interna. La documentación de DuckDB sobre espacio recuerda que los archivos de base pueden necesitar tareas de compactación o recreación para recuperar espacio.

Qué se instala o configura primero

La primera entrega verificable es una carpeta de reporte con cuatro piezas: archivo de entrada, consulta SQL, salida y README con responsable. Para una pyme con reportes semanales, alcanza una notebook o una máquina interna con DuckDB, Python, control de versiones y una carpeta respaldada. Si los archivos pesan varios gigabytes, conviene pasar a Parquet y separar datos por mes. El costo inicial puede ir de USD 600 a USD 2.000, equivalente a ARS 906.000 a 3,02 millones con dólar a $ 1.510. Incluye selección del reporte, limpieza de columnas, script, prueba de repetición y capacitación breve. La operación mensual puede quedar cerca de cero si corre en una máquina existente; sube si se suma almacenamiento externo, CI o servidor de reportes. UMSA suele pedir una prueba antes de sumar más reportes: tomar dos exportaciones reales, correr la misma consulta, comparar totales contra el ERP y guardar diferencias aceptadas. Esa prueba corta el hábito de reenviar adjuntos y deja un procedimiento que otra persona puede repetir. El primer entregable sirve si el contador puede reconstruir el resultado sin llamar al analista original.

Dónde se rompe y cómo probarlo Primer riesgo: exportar columnas sensibles por comodidad.

La señal aparece cuando el archivo tiene DNI, teléfono o correo aunque el reporte sólo necesita totales. La prueba revisa columnas autorizadas y rechaza cualquier campo fuera de la lista. Segundo riesgo: perder el filtro de origen. La señal aparece cuando nadie sabe si el CSV salió con facturas anuladas o pendientes. La prueba guarda captura o log de exportación y compara cantidad de filas contra el sistema principal. Tercer riesgo: mezclar exploración con cierre. La señal aparece cuando una consulta temporal termina en el informe mensual. La prueba exige una carpeta de consultas aprobadas y bloquea salidas generadas desde archivos sin versión. Cuarto riesgo: creer que el archivo local es respaldo de negocio. La prueba restaura el reporte en otro equipo, repite el cálculo y verifica que el dato maestro siga en la base operativa. Si la salida no se puede repetir, el reporte todavía depende de una memoria ajena. El reporte útil deja tres rastros: archivo de entrada, consulta y resultado firmado por fecha.

Para seguir leyendo

• DuckDB documentación estable
• DuckDB y archivos CSV
• DuckDB y Parquet
• DuckDB con Python
• Cómo ordenar manuales internos con Outline y PostgreSQL