Directus 11 frente a NocoDB: permisos, API y límite
Directus y NocoDB pueden ordenar datos operativos sin rehacer todo. La decisión depende de permisos, API, auditoría, costo y salida verificable.
¿Quién puede cambiar el estado de un trámite cuando la base nació como planilla compartida? Directus 11 y NocoDB atacan ese dolor desde lugares distintos: Directus toma una base SQL y entrega API, estudio visual y políticas; NocoDB acerca la experiencia de planilla a una base colaborativa. Esta guía explica dónde vive el dato, cómo se decide el permiso y qué prueba conviene hacer antes de mover un proceso real. ## Dónde aparece la planilla con demasiados dueños Stack Overflow puso a PostgreSQL primero entre las bases usadas y deseadas en su Developer Survey 2025. Ese dato importa porque muchas pymes ya tienen datos que merecen una base, aunque el proceso siga atado a una hoja con colores, filtros y celdas copiadas. La cifra corrige una costumbre local: la planilla parece barata hasta que dos personas pisan el mismo registro y nadie puede reconstruir el cambio. En un colegio profesional con 1.800 matriculados, el objeto que manda es una carpeta verde con altas, bajas y comprobantes. La secretaria no necesita una app de moda; necesita saber quién editó matrícula, cuota, domicilio y estado. Directus 11 cambió el modelo de acceso con políticas. Su página de breaking changes describe el paso a policies, y la documentación de permissions muestra reglas por colección, acción, condición, validación y campos. NocoDB trabaja con roles por organización, workspace y base, según su guía de roles and permissions. La decisión real queda en el nivel de control que necesita el proceso.
Cómo funciona por dentro
El flujo tiene cinco pasos. Primero, el equipo define entidades: matriculado, cuota, trámite, documento y evento. Segundo, PostgreSQL guarda registros estructurados, usuarios, estados y auditoría; si se usa MySQL o SQLite, la regla sigue siendo la misma: la base guarda la verdad operativa. Tercero, Directus o NocoDB exponen pantallas y API. Cuarto, roles y políticas deciden quién puede leer, crear, editar o borrar. Quinto, un backup copia base y archivos, y una restauración prueba que el trámite vuelve completo. Directus toma una base SQL y genera REST, GraphQL y una interfaz de administración. Recibe tablas, relaciones, usuarios y reglas; entrega endpoints, formularios, vistas y eventos de actividad. Si falla, la base puede seguir existiendo, pero se corta la capa de edición y API. NocoDB recibe tablas o bases propias y entrega una interfaz tipo planilla, vistas, formularios, webhooks y tokens. Su documentación de record-level security permite filtrar registros por rol, usuario o equipo en planes que lo incluyen. La guía de API tokens explica tokens con alcance fino para bases y permisos. Si falla, los usuarios pierden la vista de trabajo y las integraciones pueden recibir 401 o 403. El permiso se diseña antes del formulario. Administración edita datos de contacto y cuotas. Comisión lee reportes y aprueba cambios sensibles. Mesa de ayuda carga reclamos. Un proveedor externo ve solo tickets asignados. Nadie borra documentos; se marca baja y queda evento.
Qué se instala o configura primero
La primera instalación debe ser chica. Una VM con 2 vCPU, 4 GB de RAM, PostgreSQL 17, contenedores y backup diario alcanza para una prueba con cientos de miles de registros livianos. El costo puede ubicarse entre USD 25 y USD 70 mensuales, unos ARS 36.500 a ARS 102.300 al dólar oficial vendedor de $1.462, sin contar horas de implementación, dominio ni soporte. En Directus, el primer entregable es un modelo con cuatro colecciones, roles y una API leída por un tablero. En NocoDB, el primer entregable es una base con vistas por área, permisos de base y un token para una integración. Directus suele convenir cuando el proceso necesita API y reglas por campo desde el inicio. NocoDB suele convenir cuando el equipo necesita abandonar una planilla sin perder velocidad de carga. UMSA entra después de ordenar el flujo, con relevamiento de tablas, permisos y prueba de salida. La prueba de salida importa porque una herramienta abierta sigue siendo mala si nadie puede exportar registros, archivos y auditoría cuando cambia el proveedor.
Dónde se rompe y cómo probarlo
El primer riesgo es copiar la planilla con sus permisos malos. La señal aparece cuando un editor puede cambiar campos de auditoría. La prueba crea un usuario de cada rol y ejecuta altas, cambios, lecturas y rechazos sobre diez registros. El segundo riesgo es dejar tokens eternos. La señal aparece cuando una integración sigue escribiendo después de que cambió el proveedor. La prueba desactiva el token, revisa que la API devuelva 401 y crea uno nuevo con alcance mínimo. El tercer riesgo es olvidar los archivos. La señal aparece cuando el registro vuelve del backup, pero falta el comprobante. La prueba restaura base y almacenamiento en otro entorno, abre tres trámites y compara hash o tamaño de documentos. El cuarto riesgo es medir costo solo por licencia. La señal aparece cuando una pantalla barata exige veinte horas mensuales de limpieza. La prueba mide cantidad de pasos por trámite, errores corregidos y tiempo de cierre durante una semana. La decisión queda escrita en una tabla simple: qué dato vive en la base, qué pantalla lo edita, qué API lo lee, qué permiso lo protege y qué archivo prueba la operación.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.