n8n and backend services: Part 2 — Supabase

Supabase — a backend platform based on PostgreSQL. It combines a database, an automatically generated REST API, user sign-up and sign-in, file storage, server functions, and change subscriptions. The code is released under the Apache 2.0 license, so Supabase can be used as a cloud service or installed on your own server.

What Supabase consists of

• Database — a full PostgreSQL: tables, indexes, functions, transactions, extensions.
• REST API — generated automatically from the table structure (PostgREST): for each table read, insert, update and delete are immediately available.
• Auth — sign-up and sign-in via email and password, magic links, and external providers.
• Row Level Security — row-level access policies: a user sees only the records allowed by the policy.
• Storage — file storage with access permissions.
• Edge Functions — server-side functions in TypeScript.
• Realtime — broadcasting data changes to subscribed clients.

The main difference from document services is that this is a regular PostgreSQL. Data can be exported with standard tools (pg_dump), and any application that can work with PostgreSQL can connect to the database, including n8n.

Cloud or self-hosted

The cloud version is convenient, but its servers are located abroad, and you can’t pay the service with a Russian bank card. For personal data of Russian citizens, it is not suitable starting July 1, 2025: primary collection of such data must be conducted in databases located in Russia.

Installation on your own server is described in the official documentation: clone the repository, copy the .env.example file to .env, set secrets there, then start all services with docker compose up -d. Before the first run be sure to replace the values POSTGRES_PASSWORD, JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY and DASHBOARD_PASSWORD: the documentation explicitly warns that the service must not be run with default values.

Minimum requirements for a small working installation are 4 GB RAM, 2 cores and 40 GB on SSD; 8 GB, 4 cores and 80 GB are recommended. Unlike the cloud, a self-hosted installation does not include logs and analytics (they are added with a separate compose file), automatic backups or HTTPS: the certificate is configured on the reverse proxy, and database backups are your responsibility.

What the Supabase node can do in n8n

The built-in Supabase node works only with table rows. There are five operations:

• create a row;
• delete a row;
• get a single row;
• get all rows selected by a filter;
• update a row.

By default the node uses the public schema; you can specify another schema in the Use Custom Schema parameter.

The node’s credentials are the project address (Host) and a secret key. Supabase is moving to a new key format: old service_role keys still work for now but are being phased out, so for new connections use a secret key in the new format. The secret key bypasses Row Level Security, so it is stored only in n8n and on the server.

What the node doesn’t do

There is no arbitrary SQL, Auth user operations or Storage file operations in the node. There are two ways to handle those:

• the Postgres node with a direct connection to the Supabase database. It executes any SQL: table joins, aggregates, bulk updates. For self-hosting this is a normal PostgreSQL connection over a private network.
• the HTTP Request node to the Supabase API with the same credentials. Auth, Storage and Edge Functions are called this way.

How Supabase notifies n8n of changes

This is done with Database Webhooks. It’s a wrapper around PostgreSQL triggers and the pg_net extension: after an insert, update or delete the database asynchronously sends an HTTP request and does not delay the main transaction. Webhooks are configured in the dashboard or with an SQL query.

The request body contains JSON with fields type (INSERT, UPDATE or DELETE), table, schema, record — the row after the change — and old_record — the row before the change. In n8n such a request is received by a Webhook node, and a Switch node routes processing based on the value of type.

If Supabase and n8n are running in Docker on the same machine, the address localhost inside a container points to the container itself. Supabase documentation for this case suggests host.docker.internal; on a server it’s more convenient to place both services in the same Docker network and address n8n by the container name.

Example workflows

Leads from the website into the database. Webhook receives the form → Supabase node saves the lead to the leads table → message to the manager in Telegram. If a lead with the same phone number already exists, it’s better to find it by filtering rows and update it rather than create a duplicate.

Email about order status change. Database Webhook on the orders table → Webhook in n8n → IF: record.status differs from old_record.status → email to the customer. Comparing with the old value filters out changes that don’t affect the status.

Daily report. Schedule Trigger at 9:00 → Postgres node (Execute Query) with a query that counts orders and revenue for yesterday → message to the work chat. The aggregation is done by the database in a single query, not by n8n over thousands of rows.

Common mistakes

• Secret key in client code. Only the public key is passed to the frontend; the secret key stays in n8n.
• Table without Row Level Security. If a policy is not enabled, the public key gives access to all rows of the table via the REST API.
• Self-hosted installation without backups. Cloud backups do not transfer to your server; set up pg_dump or backup with WAL archiving.
• PostgreSQL port exposed publicly for n8n. Connect n8n to the database over a private network.
• Large fetches through the Supabase node. It’s more reliable to process thousands of rows with an SQL query on the database side.