n8n and backend services: Part 1 — Databases and BaaS in automation

While automation ties together ready-made services — CRM, email, messenger, spreadsheets — data is stored inside those services. When a custom application, a client personal account or an internal accounting system appears, data moves to a database or to a cloud backend service. Then n8n has to work with them directly: read records, create new ones, react to changes. About n8n itself, its license and installation — see the article “n8n: process automation without programming”; here we discuss how to connect it to data stores.

Two ways to work with data

Direct connection to the database. n8n connects to a DBMS over the network protocol like any regular application. There are built-in nodes for Postgres, MySQL, MongoDB, Redis and others. The Postgres node performs six operations: select rows (Select), insert (Insert), update (Update), insert or update (Insert or Update), delete (Delete) and arbitrary SQL query (Execute Query). A separate Postgres Trigger node starts the workflow when rows are inserted, changed or deleted: when the workflow is published n8n itself creates a trigger in the table and removes it when the workflow is unpublished. The n8n account needs permissions to create triggers and procedures for this.

Working via a backend service API (BaaS). Backend as a Service — a ready-made set of server-side features: database, user registration and login, file storage, server-side functions, subscription to changes. The application and n8n access it over HTTP. For some services n8n has specific nodes; for the rest the generic HTTP Request node is used.

In practice the methods are combined. Simple row operations are more convenient via the API or a specific node; reports and mass updates — via direct SQL queries.

How n8n detects changes

A workflow is triggered by an event in one of three ways.

1. Webhook from the backend. The database or service sends an HTTP request to the Webhook node in n8n when a record appears or changes. This is how Database Webhooks in Supabase, project webhooks in Appwrite, and table triggers in Xano work. This is the fastest method: the workflow starts within fractions of a second.
2. Database trigger. The Postgres Trigger node creates the trigger itself. Suitable if n8n is connected directly to PostgreSQL.
3. Scheduled polling. The Schedule Trigger node queries for new records every few minutes, for example with the field created_at greater than the last run time. This method is slower but works with any source.

With any method the workflow must be idempotent: reprocessing the same event should not create duplicates. The most reliable approach is to store a flag in the record that it has been processed, or to store the event identifier.

What changes for projects in Russia

From July 1, 2025 a new edition of Part 5 of Article 18 of Federal Law No. 152-FZ is in effect: the recording, systematization, accumulation, storage, clarification and retrieval of personal data of Russian citizens when collected must be carried out in databases located on the territory of Russia. Databases abroad are prohibited for primary collection.

For choosing a backend this means the following:

• Firebase operates in Google Cloud infrastructure abroad. In addition, since March 2022 Google Cloud does not accept new customers from Russia and does not process payments.
• Xano stores data abroad in its cloud plans; hosting on your own servers is available only on a custom/individual plan.
• Supabase and Appwrite are distributed with open source and can be installed on your own server, including with a Russian hosting provider. For personal data of Russian citizens this is a workable option. Cloud versions of these services are hosted abroad and are not suitable for such data.

If the database does not contain personal data — for example, it holds inventory balances or technical metrics — the restriction does not apply, and the choice is determined by convenience and price.

What the series covers

• Supabase — PostgreSQL with a ready API, authentication and file storage; what the n8n node can do and what must be done via SQL queries.
• Firebase — Google’s document database; which nodes exist in n8n and why this is a weak option for Russian projects.
• Appwrite — an open platform for self-hosting; working via HTTP Request and webhooks.
• Xano — a visual API builder; the n8n node and limitations of the cloud model.

Common mistakes

• Using a key with full permissions in a client application. The backend secret key bypasses access rules. It should be stored only in n8n credentials and on the server; it must not be included in the browser or mobile app.
• Opening the DBMS port to the internet for n8n. If n8n and the database are on different servers, connect them via a private network or VPN.
• Polling too frequently. Polling every minute is over 40,000 requests per month; on cloud plans that charge per operation this is a noticeable cost.
• No protection against duplicates. A repeated webhook or restarting the workflow creates a second record.
• Personal data in a foreign cloud. Check where the database is physically hosted before you start collecting data, not after.