NocoDB 2026.04 en bodegas: registros con dueño

Una bodega puede pasar recorridas, fotos y estados desde planillas a NocoDB conectado a PostgreSQL. Caso de campo con permisos, backup y prueba.

UM

ULTIMA MILLA

8 de may de 2026 · 4 min de lectura


NocoDB 2026.04 en bodegas: registros con dueño

Antes, cada recorrida de finca terminaba en una foto suelta y una fila copiada a mano; después, cada registro tuvo parcela, responsable y estado. Una bodega exportadora de Luján de Cuyo pidió ordenar inspecciones de riego, mantenimiento y calidad sin comprar otro sistema cerrado. NocoDB 2026.04 agregó vista de mapa y nuevos campos, y puede conectarse a PostgreSQL como fuente externa. La nota explica dónde vive cada dato y cómo se prueba.

El recorrido de finca pide registro antes que memoria

La cifra que corrige la rutina sale del repositorio: NocoDB supera las 62.000 estrellas en GitHub y la versión 2026.04 incorporó vista de mapa, UUID y cambios de permisos de workspace. Para una bodega, el punto operativo es concreto: una fila puede tener coordenada, foto, estado permitido y usuario responsable.

El dato global da escala. Octoverse 2025 registró más de 180 millones de desarrolladores y más de 630 millones de proyectos. La finca no necesita hablar ese idioma completo; necesita tomar una práctica básica de ese mundo: cada cambio queda fechado y puede volver a leerse. La recorrida deja de depender de la libreta que viaja en la camioneta.

La foto sin parcela envejece rápido.

El caso empezó con una carpeta llamada "campo_control_ultimo.xlsx". Tenía columnas para sector, riego, maleza, arreglo pendiente y observación. El encargado de logística revisaba la misma planilla después de cada turno y copiaba fotos desde celulares. Una Hilux blanca con barro seco en los zócalos llevaba tres libretas espiraladas en la guantera. El dato estaba, pero vivía en demasiados lugares.

La planilla de campo pierde permiso cuando sale del teléfono

El antagonista es la foto reenviada sin contexto: una válvula, una hilera, una etiqueta rota o una manguera cortada. En el chat se entiende durante veinte minutos. Dos semanas después, nadie recuerda si pertenece al cuadro 4 o al 14. La planilla conserva texto; el teléfono conserva imagen; la decisión queda partida.

NocoDB ayuda si se lo usa como capa de trabajo sobre una base clara. La documentación de self-hosting aclara que puede correrse en servidor propio y que la licencia Fair Code Sustainable Use permite uso interno, con restricciones si se ofrece como servicio gestionado a terceros. La página de fuentes de datos recomienda PostgreSQL 14 o superior para compatibilidad. La sección de permisos reúne roles, permisos de tabla, campo y registros.

Cómo funciona por dentro

El flujo mínimo tiene seis pasos. Primero, la persona de campo carga parcela, tipo de revisión, foto y estado desde un formulario. Segundo, NocoDB valida campos obligatorios y muestra opciones permitidas. Tercero, PostgreSQL guarda registros estructurados: parcela, fecha, usuario, estado, coordenada y auditoría. Cuarto, el almacenamiento S3 guarda fotos grandes y conserva metadatos. Quinto, logística consulta vistas por sector, prioridad y vencimiento. Sexto, el backup copia base y objetos, y una prueba restaura una recorrida con foto y estado.

PostgreSQL es la fuente que guarda el dato con reglas. NocoDB entrega vistas de grilla, formulario, kanban o mapa para que un usuario no técnico cargue y revise sin tocar SQL. El almacenamiento S3 separa fotos pesadas de la base. El monitoreo avisa si crece el volumen de imágenes, si una copia falla o si una recorrida queda sin responsable.

Los permisos evitan dos errores frecuentes. Campo puede crear y editar registros propios durante el turno. Logística puede reasignar estado y responsable. Calidad puede leer inspecciones cerradas. Administración puede exportar reportes. Si un proveedor carga una revisión puntual, ve solo su parcela y su contrato. La salida queda escrita cuando termina el trabajo.

Qué se instala o configura primero

La pila inicial usa NocoDB 2026.04, PostgreSQL 16 o superior, almacenamiento S3, HTTPS, correo para invitaciones y backup diario. Un piloto cuesta entre USD 900 y USD 2.700, entre ARS 1,28 y 3,83 millones al dólar vendedor oficial de $1.418 informado por Bluelytics. La operación mensual puede quedar entre USD 20 y USD 85, según fotos, usuarios y copias.

El plazo va de dos a cinco semanas. UMSA suele pedir un tablero con cuatro vistas: recorridas abiertas, arreglos vencidos, mapa de sectores y exportación mensual. El primer entregable verificable incluye veinte registros reales, dos usuarios de campo, un supervisor, tres fotos restauradas desde backup y una exportación que coincida con la base.

La implementación conviene hacerla por un flujo único. Riego o mantenimiento primero; calidad después. Si se cargan todos los procesos de finca a la vez, cada área inventa nombres de estado. Un catálogo chico evita que "revisado", "ok" y "hecho" signifiquen tres cosas distintas.

Dónde se rompe y cómo probarlo

Primer riesgo: conexión débil en campo. La señal aparece cuando el usuario guarda fotos fuera del formulario. La prueba toma diez registros en una zona de mala señal y revisa qué quedó pendiente. Segundo riesgo: permisos amplios. La señal aparece cuando un usuario de campo puede borrar una recorrida cerrada. La prueba intenta leer, editar y borrar desde cada rol.

Tercer riesgo: licencia mal entendida. La señal aparece cuando alguien propone prestar el sistema a terceros con el mismo servidor. La prueba revisa el uso previsto contra la licencia antes de vender servicio gestionado. Cuarto riesgo: backup incompleto. La señal es una restauración con filas sin fotos. La prueba devuelve una recorrida completa y abre imagen, coordenada, estado y usuario. Si la bodega puede explicar cada arreglo con parcela y fecha, la libreta deja de mandar.

Para seguir leyendo

#mendoza#nocodb#postgresql#pymes-ar