DuckDB frente a réplica PostgreSQL: costo y límite
Cómo sacar reportes pesados de producción con réplica PostgreSQL, DuckDB y Metabase: datos, permisos, archivos, costo y prueba de restauración.
Una réplica de PostgreSQL puede leer reportes largos mientras la caja diaria sigue escribiendo ventas. En una pyme de San Rafael, el reporte mensual dejó de competir con facturas, recibos y stock cuando DuckDB tomó copias acotadas y Metabase mostró tableros por grupo. Esta guía explica cuándo conviene una réplica, cuándo alcanza un archivo Parquet y cómo probar permisos, backup y costo.
Qué muestra el reporte cuando sale de producción
El reporte de cierre es útil hasta que empieza a bloquear altas, cobranzas y consultas de stock. Stack Overflow 2025 ubica a SQL con 58,6 % entre todos los respondentes, por encima de Python en esa medición. La cifra corrige una costumbre local: muchas pymes compran otro tablero antes de ordenar dónde corre la consulta. El archivo ventas_agosto.csv con 140.000 filas arriba de una carpeta compartida es el objeto que delata el problema. La decisión técnica tiene dos caminos habituales. Una réplica de PostgreSQL recibe cambios del servidor principal y acepta consultas de solo lectura; sirve cuando los reportes necesitan datos frescos y relaciones complejas. DuckDB lee archivos locales, Parquet o una conexión controlada a PostgreSQL; sirve cuando el análisis puede trabajar sobre cortes horarios o diarios. Metabase muestra el resultado a gerencia, compras o administración con permisos por grupo. Cada pieza cumple una función distinta. La documentación de PostgreSQL Hot Standby describe la posibilidad de conectar al servidor en recuperación o espera para ejecutar consultas de solo lectura. El límite operativo aparece cuando un reporte largo retrasa mantenimiento, replica datos viejos o pide columnas que el usuario no debería ver.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, la aplicación de gestión escribe facturas, recibos, artículos y movimientos en PostgreSQL principal. Segundo, la réplica recibe registros de cambios y queda disponible para lecturas. Tercero, DuckDB toma una exportación Parquet o se conecta con su extensión para PostgreSQL usando ATTACH en modo READ_ONLY cuando corresponde. Cuarto, una consulta arma tablas de trabajo: ventas por día, deuda por cliente, margen por familia o stock inmovilizado. Quinto, Metabase lee esas tablas o vistas y entrega tablero, CSV o alerta. Sexto, el backup copia base, archivos exportados y definición de tablero; una prueba restaura una consulta real. PostgreSQL guarda registros estructurados, usuarios, estados y auditoría. DuckDB recibe tablas o archivos y entrega consultas analíticas o archivos Parquet. Metabase toma una consulta guardada y muestra una vista controlada para cada grupo. El backup recupera datos, archivos y definiciones; la prueba ejecuta una pregunta concreta y devuelve filas esperadas. El permiso importa tanto como la velocidad. Según la documentación de permisos de datos en Metabase, los accesos se definen por base, esquema o tabla para cada grupo. En una pyme, gerencia puede ver ventas agregadas, administración puede descargar deuda y soporte técnico puede leer solo estado de tickets.
Qué se instala o configura primero
La primera instalación puede ser austera: PostgreSQL con réplica de lectura, un job que exporte cortes a Parquet, DuckDB en un host separado, Metabase con tres grupos y backup diario. El primer entregable verificable es un tablero con dos preguntas repetibles: ventas cobradas por semana y facturas vencidas por responsable. El costo de arranque suele quedar entre USD 350 y USD 1.200, equivalentes a ARS 537.250 y ARS 1.842.000 con dólar oficial vendedor de ARS 1.535 consultado para esta corrida. Incluye configuración de réplica, consultas iniciales, permisos, respaldo y prueba de restauración. Quedan afuera migración de ERP, limpieza de maestros duplicados y tableros comerciales de muchas áreas. UMSA usa este tipo de piloto cuando el equipo ya tiene una base con datos confiables y necesita cortar reportes manuales. El criterio de salida es medible: el tablero responde en menos de cinco segundos sobre un corte conocido, el usuario sin permiso no descarga filas sensibles y una restauración reproduce el mismo número de ventas para una semana elegida.
Dónde se rompe y cómo probarlo Primer riesgo: la réplica queda atrasada.
La señal aparece cuando el tablero muestra una cobranza que caja ya cerró. La prueba compara hora de última transacción entre primaria, réplica y tablero cada quince minutos durante un día de carga. Segundo riesgo: DuckDB escribe donde debía leer. La señal aparece cuando un usuario ejecuta ATTACH sin READ_ONLY contra la base operativa. La prueba usa una credencial de solo lectura y rechaza cualquier sentencia de cambio. Tercer riesgo: el CSV expone datos personales. La señal aparece cuando una descarga contiene CUIT, teléfono o mail sin motivo. La prueba abre cada pregunta de Metabase con usuario de gerencia y revisa columnas exportables. Cuarto riesgo: el backup guarda la base y pierde Parquet o definiciones de tablero. La señal aparece cuando la restauración responde con tablas vacías. La prueba reconstruye un tablero desde cero en otro host y compara dos cifras. El cierre es simple: si el reporte toca caja, debe tener dueño, permiso y una forma de volver.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.