n8n y servicios de backend: Parte 1 — Bases de datos y BaaS en la automatización

Mientras la automatización conecta servicios ya existentes —CRM, correo, mensajería, hojas de cálculo—, los datos se almacenan dentro de esos servicios. Cuando aparece una aplicación propia, un área de cliente o un sistema interno de contabilización, los datos se mudan a una base de datos o a un servicio backend en la nube. Entonces n8n tiene que trabajar con ellos directamente: leer registros, crear nuevos, reaccionar a cambios. Sobre n8n, su licencia e instalación —en el artículo «n8n: automatización de procesos sin programación»; aquí se trata de cómo conectarlo a almacenes de datos.

Dos maneras de trabajar con los datos

Conexión directa a la base de datos. n8n se conecta al SGBD por el protocolo de red, como una aplicación normal. Para ello hay nodos integrados Postgres, MySQL, MongoDB, Redis y otros. El nodo Postgres realiza seis operaciones: selección de filas (Select), inserción (Insert), actualización (Update), inserción o actualización (Insert or Update), eliminación (Delete) y consulta SQL arbitraria (Execute Query). Un nodo independiente Postgres Trigger inicia el proceso cuando se insertan, modifican o eliminan filas: al publicar un flujo n8n crea él mismo el trigger en la tabla y lo elimina cuando se deja de publicar el flujo. La cuenta de n8n necesita permisos para crear triggers y procedimientos.

Trabajo vía API del servicio backend (BaaS). Backend as a Service —conjunto listo de funciones del servidor: base de datos, registro e inicio de sesión de usuarios, almacenamiento de archivos, funciones en el servidor, suscripción a cambios. La aplicación y n8n acceden a él por HTTP. Para algunos servicios n8n tiene nodos específicos; para el resto se usa el nodo genérico HTTP Request.

En la práctica se combinan los métodos. Operaciones simples sobre filas son más cómodas vía API o con un nodo específico; informes y cambios masivos —con consultas SQL directas.

Cómo n8n detecta cambios

Un proceso se inicia por un evento de una de tres maneras.

1. Webhook desde el backend. La base o servicio envían una petición HTTP a la URL del nodo Webhook en n8n cuando aparece o cambia un registro. Así funcionan los Database Webhooks en Supabase, los webhooks de proyecto en Appwrite, los triggers de tablas en Xano. Es la forma más rápida: el proceso arranca en fracciones de segundo.
2. Trigger de la base de datos. El nodo Postgres Trigger crea el trigger por sí mismo. Sirve si n8n está conectado a PostgreSQL de forma directa.
3. Polling según programación. El nodo Schedule Trigger consulta cada pocos minutos los registros nuevos, por ejemplo con el campo created_at mayor que la hora de la última ejecución. Es más lento, pero funciona con cualquier fuente.

Con cualquier método el proceso debe ser idempotente: el re-procesado de un mismo evento no debe crear duplicados. Lo más fiable es guardar en el registro una marca de que ya se procesó, o el identificador del evento.

Qué cambia para proyectos en Rusia

Desde el 1 de julio de 2025 entra en vigor la nueva redacción del apartado 5 del art. 18 de la ley nº 152-FZ: la recopilación, sistematización, acumulación, almacenamiento, aclaración y extracción de datos personales de ciudadanos de Rusia al momento de su recogida debe realizarse en bases de datos ubicadas en el territorio de Rusia. Está prohibido usar bases en el extranjero para la recolección primaria.

Para elegir backend esto significa lo siguiente:

• Firebase funciona en la infraestructura de Google Cloud en el extranjero. Además, desde marzo de 2022 Google Cloud no acepta nuevos clientes de Rusia y no realiza pagos.
• Xano en los planes en la nube aloja los datos en el extranjero, y el alojamiento en sus propios servidores está disponible solo en un plan individual.
• Supabase y Appwrite se distribuyen con código abierto y se instalan en un servidor propio, incluido en un proveedor de hosting ruso. Para datos personales de ciudadanos de Rusia es una opción válida. Las versiones en la nube de estos servicios están alojadas en el extranjero y no son adecuadas para esos datos.

Si en la base no hay datos personales —por ejemplo, son existencias de almacén o métricas técnicas— la restricción no se aplica y la elección la determinan la conveniencia y el coste.

Qué cubre el ciclo

• Supabase —PostgreSQL con API lista, autenticación y almacenamiento de archivos; qué puede hacer el nodo de n8n y qué hay que resolver con SQL.
• Firebase —base documental de Google; qué nodos hay en n8n y por qué es una opción débil para proyectos rusos.
• Appwrite —plataforma de código abierto para instalar en servidor propio; trabajo vía HTTP Request y webhooks.
• Xano —constructor visual de APIs; nodo de n8n y las limitaciones del modelo en la nube.

Errores típicos

• Clave con permisos completos en la aplicación cliente. La clave secreta del backend elude las reglas de acceso. Debe guardarse solo en las credenciales de n8n y en el servidor; no debe llegar al navegador ni a la app móvil.
• Puerto del SGBD abierto en internet por n8n. Si n8n y la base están en servidores distintos, conéctelos por red privada o VPN.
• Polling demasiado frecuente. Consultar cada minuto son más de 40 000 peticiones al mes; en planes en la nube con facturación por operaciones supone un coste notable.
• No hay protección contra duplicados. La repetición de un webhook o el reinicio de un flujo crea una segunda entrada.
• Datos personales en una nube extranjera. Compruebe dónde se aloja físicamente la base antes de empezar a recopilar datos, no después.