NocoDB Review 2026: análisis completo de la alternativa open source a Airtable

Tarde o temprano casi todos los equipos chocan con el mismo muro: los datos viven en Google Sheets, la hoja crece hasta cien pestañas vinculadas, las fórmulas se rompen con cada fila insertada y la mitad del equipo edita la columna equivocada. Airtable resolvió esto con elegancia y trajo consigo una factura por usuario y una pregunta incómoda: ¿de verdad queremos los datos de clientes en la nube de otro?

NocoDB es la respuesta más popular a ambos problemas a la vez. Es una plataforma open source que convierte una base de datos SQL corriente en una hoja inteligente con formularios, kanban, roles y API REST. El proyecto nació de la idea de «Airtable sobre tu propia base de datos» y en 2026 acumula más de 50.000 estrellas en GitHub, decenas de miles de instalaciones autoalojadas y un producto cloud comercial completo.

En este análisis vemos cómo funciona NocoDB por dentro, qué hace realmente bien, dónde duele, cuánto cuesta la nube y qué implica tenerlo en un servidor propio — con un veredicto honesto al final: quién debería migrar y quién está mejor en Airtable o mirando Baserow.

Qué es NocoDB y cómo está construido

La idea arquitectónica central es simple, y precisamente por eso es valiosa: NocoDB no guarda tus datos en un formato propietario. Se conecta a una base de datos relacional existente — PostgreSQL, MySQL/MariaDB, SQLite y, en versiones recientes, Microsoft SQL Server — y pinta encima una interfaz web tipo hoja de cálculo.

Qué significa en la práctica:

• Cada tabla de NocoDB es una tabla real en tu base de datos. Cada columna es una columna real. Cada fila es un registro normal.
• Puedes conectarte a la misma base con psql, lanzar SQL, alimentar una herramienta de BI o entregar los datos a una aplicación existente en cualquier momento.
• Si NocoDB desapareciera mañana (los proyectos open source son mortales), tus datos seguirían en una base estándar, no en una exportación cerrada.

El stack tampoco es exótico: backend en Node.js, frontend en Vue, todo empaquetado como imagen Docker. Para autoalojarlo eso significa un docker run y un par de variables de entorno — sin clúster, sin almacenamiento de objetos obligatorio, sin Redis.

Conviene aclarar la diferencia entre los dos formatos de entrega, porque la confusión aquí es constante:

1. NocoDB Open Source — la versión gratuita que despliegas tú. Funciones centrales: tablas, vistas, roles, API, webhooks. Los límites afectan a temas empresariales avanzados: SSO, auditoría y permisos granulares.
2. NocoDB Cloud — el servicio gestionado por los desarrolladores, donde la infraestructura es suya. Ahí viven también los planes de pago con límites mayores.

La tercera opción, la menos evidente, es la base de datos externa: puedes conectar una instancia de Postgres que ya sostiene tu producto y obtener una interfaz de administración cómoda sobre datos de producción. Útil para soporte y analítica, pero con cuidado: una interfaz web no sustituye a las migraciones.

Para quién tiene sentido NocoDB

Según la experiencia real, NocoDB brilla en cuatro escenarios.

Tablas operativas internas. CRM ligero, base de clientes, seguimiento de tickets, inventario, registro de contratos. Todo lo que antes vivía en Google Sheets y ya no cabía.

Sustituir un panel de administración casero. Si tienes base de datos y necesitas interfaz para operadores — formularios, filtros, permisos — NocoDB cubre el 80% sin una línea de frontend.

Capa sobre una base heredada. Una vieja base MySQL del sistema contable a la que nadie se atreve a acercarse. NocoDB le da una interfaz humana segura con acceso por roles.

Prototipo rápido de producto. Cuando hace falta un backend CRUD funcional con API de un día para otro y no un sprint de Nest.js.

Y dónde no conviene usarlo:

• Como base principal de un producto de alta carga con miles de usuarios concurrentes.
• Como almacén de archivos o mediateca — los adjuntos funcionan, pero esto no es S3.
• Como sustituto de un BI de verdad: hay tablas dinámicas y gráficos, pero no analítica profunda.
• Para equipos que necesitan modo offline y apps móviles nativas al nivel de Airtable.

Ventajas y desventajas

Ventajas

• Código abierto con autoalojamiento real, sin salvedades de «solo nube».
• Los datos están en tu base SQL, accesibles por SQL y por cualquier cliente.
• La versión gratuita es funcionalmente completa para equipos de 10–20 personas.
• API REST y GraphQL listas para cada tabla, documentadas en la interfaz.
• Muchas vistas: cuadrícula, formulario, galería, kanban, calendario, mapa.
• Roles desde propietario hasta solo lectura y comentarista.
• Webhooks y automatizaciones por eventos de registro.
• Comunidad activa y versiones frecuentes; el proyecto está vivo.

Desventajas

• La interfaz a veces pesa: con 50+ columnas y decenas de miles de filas el navegador empieza a pensar.
• Las fórmulas y los rollups funcionan, pero quedan por detrás de Airtable en profundidad y depuración.
• Las automatizaciones son modestas: ramificaciones complejas y disparadores externos requieren apaños.
• No hay apps móviles nativas, solo versión web adaptable.
• El autoalojamiento exige conocimientos: Docker, proxy inverso, copias de seguridad y actualizaciones son tu responsabilidad.
• Las actualizaciones mayores a veces requieren migración manual del esquema.
• Algunas funciones empresariales (SSO, auditoría, permisos granulares) son de pago.

Funciones: qué hace NocoDB realmente en 2026

Vistas

Una tabla, muchas vistas, y no es una frase de marketing. La cuadrícula es el modo base con filtros, ordenación, agrupación y columnas fijadas. El formulario publica un enlace público y recoge datos de gente externa sin acceso a la base. La galería muestra registros como tarjetas con portada, ideal para catálogos. El kanban agrupa por un campo de estado con arrastrar y soltar. El calendario vincula registros a fechas y el mapa a coordenadas.

Cada vista guarda sus filtros y ajustes por separado. Para un operador esto significa que el mismo conjunto de datos aparece como «todos los tickets», «mis tickets abiertos» y «vencidos» sin duplicar tablas.

Tipos de campo

El repertorio es amplio: texto, número, fecha y hora, casilla, selección simple y múltiple, email, URL, teléfono, moneda, porcentaje, valoración, fórmula, rollup, lookup, relaciones (uno a uno, uno a muchos, muchos a muchos), archivos adjuntos, JSON, geodatos, código de barras, texto largo y campo de usuario/asignado.

Las relaciones se implementan con claves foráneas reales y no con identificadores de texto — algo que se nota en las migraciones y al trabajar con los datos desde fuera.

API

Cada tabla obtiene automáticamente una API REST: listar registros con filtros y paginación, crear, actualizar, borrar y operaciones masivas. Además un endpoint GraphQL para consultas complejas y tokens de acceso limitados por tabla.

Este es el punto que separa a NocoDB de «una hoja bonita»: puedes escribir un bot, un script en Python o una app móvil contra la misma base mediante una API documentada mientras el equipo sigue editando datos a mano en el navegador.

Roles y acceso

Niveles: Owner, Creator, Editor, Commenter, Viewer. Los permisos se conceden por base y por tabla. Además hay enlaces públicos a vistas — con o sin contraseña, con la descarga de adjuntos desactivable.

En la edición open source los permisos granulares (a nivel de fila y columna) son limitados — una de las razones principales por las que las empresas compran licencia.

Webhooks y automatizaciones

Los webhooks se disparan al crear, actualizar y borrar registros y envían JSON a tu endpoint. El constructor de automatizaciones integrado resuelve cadenas simples: «al cambiar el estado — enviar email», «según horario — crear registro», «al llegar un registro — llamar a una API externa».

Para orquestación completa no basta — lo habitual es usar NocoDB como fuente de datos y llevar la lógica a n8n, Make o un servicio propio.

Precios: nube frente a servidor propio

Aquí conviene llamar a las cosas por su nombre, porque la parrilla de precios de NocoDB ha cambiado varias veces y las cifras exactas deberían verificarse en la web oficial al leer esto.

Open Source (autoalojado) — gratis. La imagen Docker completa, sin límites de registros, tablas ni usuarios. Solo pagas el servidor.

Cloud Free — un plan gratuito para equipos pequeños: sirve para probar el producto, pero con límites de usuarios y filas.

Planes Cloud de pago — por asiento con facturación anual. Los planes altos levantan los límites de asientos: hay ofertas de «usuarios ilimitados por una cuota mensual fija» — para 15–30 personas es matemáticamente más barato que Airtable Team.

Business/Enterprise autoalojado — licencia de pago para tu propia instalación, calculada por editor (no por lector). Aporta SSO, auditoría, permisos ampliados y soporte prioritario.

La aritmética simple que conviene retener: un VPS capaz de sostener NocoDB con una base de 5–10 GB cuesta menos que diez asientos en la nube. Por eso el autoalojamiento es el escenario principal de este producto.

Prueba práctica: desplegar NocoDB en un VPS

Desplegamos NocoDB dos veces: con Docker Compose y PostgreSQL en un VPS, y como «SQLite dentro del contenedor» para comparar.

Recursos necesarios

• Mínimo: 2 vCPU, 2 GB de RAM, 20 GB SSD — para equipos de hasta 10 personas y bases de cientos de miles de registros.
• Cómodo: 4 vCPU, 4–8 GB de RAM, NVMe — para 20–50 usuarios activos y millones de filas.
• PostgreSQL, no SQLite — si hay más de un par de gigabytes de datos o más de cinco usuarios. SQLite va bien para una prueba, pero los bloqueos de escritura se notan.

Un Compose de dos servicios (nocodb + postgres) arranca en cinco minutos. Solo el puerto 8080 debe mirar a internet, detrás de un proxy inverso con TLS — Nginx o Caddy, el segundo más simple para certificados.

Dónde alojarlo

Elige un proveedor con hardware local y control real. Nosotros ejecutamos la instalación en Timeweb Cloud: ofrece imágenes listas para Docker y red privada, cómodo si luego mueves Postgres a otra máquina. Para presupuesto mínimo funcionó FirstVDS: configuraciones más sencillas, pero KVM honesto sin sobreprecio de panel. El dominio se registró en REG.RU, que además da gestión DNS gratuita.

Qué comprobamos a mano

Velocidad de la interfaz. Una tabla de 60.000 filas y 25 columnas abre en 1,5–2 segundos, el filtrado es instantáneo y la paginación funciona. Con 500.000 filas la cuadrícula empieza a arrastrarse de forma perceptible: NocoDB pagina los datos, pero ordenar por un campo sin índice obliga a esperar. Conclusión: los índices en la base siguen siendo necesarios, y añadirlos es más fácil en SQL que desde la interfaz.

Importación de CSV. Un archivo de 40 MB con 200.000 filas subió en torno a un minuto con inferencia de tipos correcta. Los acentos y caracteres no ASCII sobrevivieron sin daño — importante en proyectos localizados.

Búsqueda. La búsqueda de texto completo funciona a nivel de ILIKE de la base, es decir, sin lematización. Para búsqueda seria hay que añadir pg_trgm o un índice externo.

Roles. Probamos «el operador solo ve sus tickets»: en la edición open source esto es un filtro de vista más una cuenta separada, no seguridad real a nivel de fila. El RLS de verdad es de pago o se hace con vistas en la propia base.

Copias de seguridad. No hay planificador integrado. El esquema que funciona: pg_dump por cron a almacenamiento de objetos más una copia aparte del volumen de adjuntos. Esto es lo primero tras instalar: restaurar una interfaz sin su base no sirve de nada.

Actualizaciones. Cambiar la etiqueta de la imagen y ejecutar docker compose up -d. Con versiones menores no hubo problemas; en un salto mayor hizo falta una migración manual — lee las notas de versión antes de saltar.

Adjuntos. Los archivos se guardan en un volumen local del contenedor o en almacenamiento compatible con S3. Si el equipo sube contratos escaneados, S3 es obligatorio; de lo contrario la copia del volumen crece sin control.

Lo que faltó

• Un registro de auditoría real por registro — no existe en la versión gratuita.
• Edición masiva de fórmulas desde la interfaz.
• Diagnóstico claro de consultas lentas: acabas en los logs de Postgres.

NocoDB frente a la competencia

Airtable. Airtable sigue siendo más agradable en los detalles: interfaces, automatizaciones, apps móviles, ecosistema. Pero los datos están con el proveedor y el precio por asiento para 20 personas se vuelve incómodo. NocoDB gana en control y coste total, Airtable en pulido.

Baserow. El competidor open source más cercano. Baserow apuesta por la simplicidad y un formato de datos propio (aunque ya soporta bases externas). Su interfaz es más agradable y rápida; NocoDB es más profundo conectando bases SQL existentes y en la capa de API.

SeaTable. Fuerte en fórmulas y lógica de hoja, más cerca de Excel. Proyecto alemán con buen autoalojamiento, pero comunidad menor.

Teable. Proyecto joven con interfaz moderna y foco en rendimiento; prometedor para tablas muy grandes, aunque su ecosistema y documentación aún son más finos.

Google Sheets. Gratis y familiar, pero no da roles, ni relaciones, ni disciplina de API. Cuando hay más de dos editores y entidades vinculadas, toca moverse.

Veredicto

NocoDB es la mejor opción en 2026 si necesitas una capa tipo Airtable sobre tu propia base SQL y estás dispuesto a dedicar una tarde a Docker, dominio y copias de seguridad. A cambio obtienes control total de los datos, uso gratuito para equipos de cualquier tamaño y una API a la que puedes conectar lo que sea.

No elijas NocoDB si todo el equipo es poco técnico y nadie va a responsabilizarse del servidor; si necesitas automatizaciones al nivel de Airtable; si las apps móviles nativas son críticas; o si exiges auditoría estricta y seguridad a nivel de fila sin comprar licencia.

Encaja mejor en: equipos de producto y operaciones de 5–30 personas, agencias, proyectos SaaS pequeños ya sobre Postgres y cualquiera cansado de pagar por asiento en hojas en la nube.

Consejo de implantación: empieza con la versión autoalojada en un VPS con 4 GB de RAM y PostgreSQL — suficiente para el primer año. Trata NocoDB como capa sobre la base, no como el único lugar donde viven los datos, configura pg_dump el primer día y mueve los adjuntos a S3. Si tras un mes el equipo lo usa activamente, mira una licencia para SSO y auditoría — no al revés.

¿Y cómo tienes organizadas tus tablas internas: todavía Google Sheets o ya algo como NocoDB?