El problema con undb en 2025–2026
Un proyecto open source no está condenado por el mero hecho de ralentizarse. Algunos alcanzan una madurez estable y simplemente no necesitan muchos cambios. undb no encaja en ese perfil: es una herramienta joven en una categoría que evoluciona rápidamente, con dependencias JavaScript de vida corta.
Las señales de alerta acumuladas a finales de 2025 son concretas. El último tag publicado tenía más de sesenta días de antigüedad a fin de año. El número de issues abiertas sin comentario de un mantenedor superaba las treinta. Varias reportaban regresiones en funcionalidades clave — fórmulas, vistas filtradas, importación CSV — sin confirmación de tratamiento. La última actualización de dependencias npm tenía meses, dejando CVEs conocidos sin parchear en la cadena de dependencias.
El problema no es solo técnico. Una herramienta de base de datos aloja datos operacionales. Cuando el mantenimiento flojea, la pregunta ya no es «¿funciona hoy?» sino «¿funcionará en seis meses, y estarán mis datos accesibles si no es así?». Con undb en su estado actual, la respuesta es incierta.
Por qué migrar ahora y no en seis meses
- Riesgo de seguridad activo: las dependencias npm sin actualizar acumulan CVEs conocidos; una instancia de undb expuesta a Internet sin un reverse proxy reforzado es una superficie de ataque creciente.
- Bugs sin corregir en producción: las regresiones en la importación CSV y las fórmulas reportadas a finales de 2025 no tienen solución; si tu uso toca estas funcionalidades, la situación solo empeora.
- Dependencias congeladas: Node.js LTS avanza, las imágenes base de Docker cambian; un proyecto sin mantenimiento acaba fallando en la compilación, bloqueando las actualizaciones de seguridad del host.
- La comunidad se mueve: las discusiones en foros de self-hosting (Reddit r/selfhosted, awesome-selfhosted) muestran una tendencia clara hacia Teable, NocoDB y Grist; quedarse en undb significa perder acceso a integraciones activas y scripts de la comunidad.
- Datos huérfanos: cuanto más tiempo pasa, mayor es la probabilidad de un cambio interno de esquema no documentado; exportar ahora, cuando el formato de salida es conocido y estable, es más seguro que esperar una futura incompatibilidad.
- Ventana de migración limpia: tus datos están frescos y consistentes ahora; una migración forzada — porque la instancia no arranca tras una actualización de Docker — siempre ocurre en peores condiciones.
Teable: la base de datos NoCode en Rust con mantenimiento activo
Teable se presenta como una alternativa a Airtable en self-hosted, pero su posicionamiento técnico es más preciso. El backend está escrito en Rust con NestJS para la capa API, y la interfaz es una aplicación React. Esto produce un backend que consume aproximadamente 150–200 MB de RAM en reposo, frente a los 400–600 MB de undb en una instancia comparable.
La API REST está documentada y diseñada para ser compatible con los patrones de Airtable: mismos conceptos (tablas, vistas, campos, registros), mismos verbos HTTP, estructuras JSON similares. Si tienes scripts que consultaban undb a través de su API, adaptarlos a Teable se reduce a ajustar algunas rutas y nombres de campos.
La licencia AGPL-3.0 restringe la redistribución de builds modificados de Teable, pero no impone ninguna restricción para el uso interno o para desplegar Teable para tus propios clientes en tu propia infraestructura.
La cadencia de releases es el punto más importante para una herramienta en producción: releases semanales a quincenales con changelogs detallados, bugs críticos tratados en menos de 72 horas, y una hoja de ruta pública actualizada.
undb vs Teable: comparativa técnica
Desplace la tabla
| Criterio | undb | Teable |
|---|---|---|
| Lenguaje backend | TypeScript (Node.js) | Rust + NestJS |
| Licencia | AGPL-3.0 | AGPL-3.0 |
| RAM en reposo (Docker) | ~400–600 MB | ~150–200 MB |
| API compatible con Airtable | Parcial, no documentada | Sí, documentada |
| Importación CSV/JSON | Sí (regresiones reportadas a finales de 2025) | Sí, estable |
| Estrellas GitHub (otoño 2026) | ~3.500 | ~12.000+ |
| Actividad de mantenimiento | Estancada (>60 días sin release, finales 2025) | Activa (releases semanales) |
Preparar la migración: exportar desde undb
Antes de instalar nada, realiza la exportación de undb desde una instancia aún funcional. No lo dejes para después de instalar Teable: si algo sale mal entre los dos pasos, querrás tener tus datos a mano.
Exportar tus datos desde undb
Acceder a la interfaz de exportación
En undb, abre cada tabla que quieras migrar. El menú contextual de la tabla (icono «…» o clic derecho en la pestaña) expone una opción «Export». undb ofrece dos formatos: CSV y JSON. Elige JSON para las tablas con campos de tipo relación o fórmula — el CSV aplana las relaciones en cadenas de texto, lo que complica el remapeo. Para tablas simples (sin relaciones), el CSV es suficiente.
Exportar tabla por tabla
undb no ofrece una exportación global de base de datos en esta versión. Hay que exportar cada tabla por separado. Organiza tus archivos en una carpeta con el nombre de la base: por ejemplo
export-undb-crm/. Anota el orden de importación futuro: las tablas referenciadas por otras deben importarse primero en Teable.Verificar la integridad de las exportaciones
Para cada archivo JSON exportado, verifica que no esté truncado: ábrelo en un editor o ejecuta
python3 -m json.tool mi-export.json > /dev/null— sin salida de error indica JSON válido. Para archivos CSV, cuenta las líneas conwc -l export.csvy compara con el número de registros mostrado en undb.Conservar una copia de archivo
Antes de continuar, archiva todo:
tar czf undb-export-$(date +%Y%m%d).tar.gz export-undb-*/. Conserva este archivo durante treinta días después de la migración. Si Teable revela una inconsistencia de datos dos semanas después de la importación, la exportación original de undb es tu referencia de verdad.
Instalar Teable en un VPS ServOrbit
ServOrbit ofrece una plantilla Teable en su marketplace en /marketplace/bases-de-donnees/teable. La plantilla configura automáticamente Docker Compose, las variables de entorno base y el reverse proxy. Para una instalación manual completa en Debian 12 o Ubuntu 22.04, los pasos siguientes cubren el procedimiento completo.
Instalar Teable vía Docker Compose
Crear el directorio de trabajo
Conéctate por SSH a tu VPS. Crea un directorio dedicado y navega hasta él:
mkdir -p /opt/teable && cd /opt/teableDescarga el archivo Compose oficial:
curl -O https://raw.githubusercontent.com/teableio/teable/main/dockers/docker-compose.ymlConfigurar las variables de entorno
Crea un archivo
.enven/opt/teable/. Las variables mínimas requeridas son:POSTGRES_PASSWORD=cámbiame-fuerte TEABLE_SECRET_KEY=una-cadena-aleatoria-32-caracteres PUBLIC_ORIGIN=https://teable.tu-dominio.tldGenera la clave secreta con
openssl rand -hex 16. No reutilices la contraseña de PostgreSQL de otra instancia.Iniciar los servicios
Lanza el stack en segundo plano:
docker compose up -dEspera treinta segundos, luego verifica que los contenedores están en estado
healthy:docker compose psConfigurar el reverse proxy
Teable escucha en el puerto 3000 por defecto. Configura tu reverse proxy (nginx o Caddy) para redirigir el tráfico HTTPS a
localhost:3000. Ejemplo mínimo de nginx:server { listen 443 ssl; server_name teable.tu-dominio.tld; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }Primer acceso y creación de cuenta administrador
Abre
https://teable.tu-dominio.tlden un navegador. En el primer acceso, Teable propone crear una cuenta de administrador. Esta cuenta es local a tu instancia — sin registro externo. Elige una contraseña fuerte y guárdala en tu gestor de secretos.Crear un espacio de trabajo
Tras el login, crea un espacio de trabajo (equivalente a una organización en Airtable) que alojará las bases migradas desde undb. Dale un nombre descriptivo —
Migración undbpor ejemplo — para distinguir los datos importados de las nuevas bases que crearás directamente en Teable.
Importar tus datos de undb en Teable
Teable ofrece dos vías de importación: CSV para tablas simples, y JSON estructurado para tablas con tipos de campos complejos. La interfaz de importación está accesible desde el menú '+' de un espacio de trabajo.
Importar y verificar los datos
Crear la base destino en Teable
En tu espacio de trabajo, haz clic en «Nueva base» y dale el mismo nombre que la base original en undb. Esta consistencia de nomenclatura facilita la verificación cruzada durante la migración.
Importar las tablas desde CSV o JSON
Dentro de la base destino, haz clic en «+ Añadir tabla» y luego «Importar desde archivo». Selecciona tu exportación CSV o JSON. Para CSV, Teable detecta automáticamente los tipos de columna — verifica que las columnas de fecha se interpreten como
Datey no comoText.Importa primero las tablas sin relaciones, luego las que las referencian.
Mapear y ajustar los tipos de campo
Tras la importación, revisa cada columna en Teable y verifica su tipo. Puntos problemáticos comunes al migrar desde undb:
- Los camposformulade undb llegan como valores calculados congelados — recrea las fórmulas en Teable manualmente.
- Los camposattachmentno migran por CSV; si undb almacenaba archivos, trátelos por separado.
- Los campos booleanos exportados como cadenatrue/falsedeben convertirse al tipoCheckboxen Teable.Verificar las relaciones y la integridad de los datos
Si tus tablas de undb tenían relaciones (campos de tipo enlace), estas llegan aplanadas en la exportación CSV. Recrea los campos de enlace en Teable una vez importadas todas las tablas, luego usa la vista de filtrado para verificar que el número de registros coincide con el original.
Prueba primero en una base no crítica
Antes de migrar tus datos de producción, aplica el procedimiento completo en una base secundaria — datos de prueba, un proyecto archivado, o una copia anonimizada. Esto revela problemas de mapeo de tipos de campo y casos límite propios de tu uso sin arriesgar la integridad de los datos operacionales.
Conserva el archivo de exportación de undb durante al menos treinta días después de la migración. Si aparece una inconsistencia de datos dos semanas después de la importación, la exportación original es tu única fuente de verdad. Una vez transcurrido ese plazo y validada la migración completamente, podrás desactivar la instancia de undb con total confianza.