How to Connect n8n to a Database

Updated 2026-10-10 · 1185 words

This page may contain affiliate links. If you buy through them we may earn a commission at no extra cost to you.

Direct answer: connecting n8n to a database means adding the dedicated node for your database engine, Postgres, MySQL, MariaDB, or MSSQL, creating a credential with your host, port, database name, and login, then choosing an operation: Execute Query for raw SQL, or the node's built-in Insert/Update/Select helpers for simpler cases. The two details that trip people up are SSL mode (most managed databases require it) and reachability (n8n Cloud needs a publicly reachable database or a tunnel). Here's the full setup, including the mistakes that cause a workflow to fail silently instead of loudly.

Step 1: Pick the right node for your database engine

n8n ships dedicated nodes for Postgres, MySQL, MariaDB, and Microsoft SQL Server, each with its own credential type and query helpers. If you're running something else, SQLite, Oracle, a cloud data warehouse, check first whether a community node exists before falling back to a generic approach; n8n's node search surfaces community-maintained database connectors that cover most of the gap. For anything with no dedicated node at all, an HTTP Request node against a REST API in front of the database is usually more reliable than trying to speak its wire protocol directly from a workflow.

Step 2: Gather your connection details

You'll need the host (an IP or hostname, never localhost unless n8n and the database run in the same container network), port (5432 for Postgres, 3306 for MySQL by default), database name, username, and password. If your database sits behind a managed provider, Supabase, Neon, Amazon RDS, DigitalOcean's managed databases, these details are usually on a "Connection" tab in that provider's dashboard, often with a ready-made connection string you'll need to pick apart into its individual fields since n8n's credential form wants them separately rather than as one URL.

Step 3: Create the credential and confirm SSL mode

In n8n, add a new credential of the matching type (Postgres, MySQL, and so on) and fill in the fields from Step 2. This is where most first connections fail: leave SSL on its default and a managed database that requires an encrypted connection will reject it with an error that doesn't always say "SSL" in plain language. Set SSL to Enabled (or Require, depending on the node's exact wording) whenever you're connecting to anything that isn't a database on your own private network, and use Disable only for a local or same-network setup where encryption isn't doing any work. Test the credential immediately after saving it rather than wiring a whole workflow first and debugging a connection failure after the fact.

Step 4: Confirm the database is actually reachable

This step only matters if you're on n8n Cloud or any setup where n8n and the database live on different networks. A database that only accepts connections from its own VPC or from localhost won't accept a connection from n8n's servers until you either open a firewall rule for n8n's outbound IP ranges (published in n8n's docs) or put a tunnel in front of it. Self-hosted n8n running in the same Docker network or VPC as the database skips this entirely, since the two can already reach each other over the internal network, which is one real advantage of self-hosting both side by side.

Step 5: Run your first query with parameters, not string concatenation

Add the database node to a workflow and choose Execute Query for raw SQL, or one of the node's structured operations (Insert, Update, Select, Delete) if your use case is simple enough not to need custom SQL. Whichever you pick, use the node's query-parameter fields ($1, $2 for Postgres; ? markers for MySQL) to pass in values from earlier nodes, rather than building the SQL string yourself with an expression that drops user or workflow data straight into the query text. Parameterized queries aren't a style preference here, they're what stops a webhook-triggered workflow from becoming a SQL injection path the moment someone sends unexpected input.

Step 6: Handle large result sets deliberately

A Select or Execute Query operation pulls every matching row into memory in one pass. Looping a workflow over a table with tens of thousands of rows this way is a common way to watch a workflow run out of memory or simply time out. Add an explicit LIMIT and OFFSET (or a keyset-based cursor on an indexed column, which scales better than OFFSET on a large table) and paginate through results in batches, or push the heavy filtering and aggregation into the SQL itself rather than pulling raw rows out to filter in n8n.

Step 7: Decide how writes should behave on failure

Database writes inside a workflow need a clear answer to "what happens if this fails partway through." For a handful of related inserts, wrap them in a transaction if your node and database support it, so a failure midway rolls everything back instead of leaving half-written data. For simpler single-row writes, make sure the workflow's error-handling settings (continue on fail, or stop and alert) match what's actually safe for that data; silently continuing past a failed insert that should have blocked the rest of the workflow is a quiet way to end up with data that doesn't match what you think happened.

Database connections compared

Common pitfalls

SSL mode left on the default is the single most common first-connection failure, especially against managed providers that require it silently rather than with a clear error message. Second, string-building SQL instead of using parameterized fields, safe when every value is hardcoded, a real risk the moment any value comes from a webhook, a form, or anything else outside your control. Third, pulling an entire table into memory with no LIMIT, which works fine in testing on a small table and fails without warning once the table grows. Test the credential on its own before wiring a workflow around it, and you'll catch most of these before they cost you a debugging session.

If your workflow's real job is getting data into a database rather than a one-off query, our guide to automating data entry with AI covers the upstream extraction step, and our guide to using Google Sheets with n8n is worth reading if a spreadsheet is actually a better fit than a full database for your current volume. For the self-hosting side of this setup, our guide to running n8n with Docker covers putting n8n and a database on the same network so you can skip the public-reachability step entirely. PostgreSQL's own documentation is worth a read for connection-parameter and SSL-mode specifics this guide doesn't have room to cover in full, and n8n publishes node-specific docs for every database connector mentioned here.

Save this to Pinterest