Skip to main content

PostgreSQL node

The PostgreSQL node (type DATABASE_POSTGRESQL) executes SQL queries on a PostgreSQL database directly from a workflow. It is used to read or write data (SELECT, INSERT, UPDATE, DELETE, DDL), to enrich the context before an HTTP node or a business processing, and to persist data received by a trigger (webhook, Scheduler, file, etc.).

Parameters​

ParameterTypeRequiredDefaultDescription
AppApp❌—Application associated with the node. See Apps.
Host (host)String✅—Hostname or address of the PostgreSQL server. Supports Handlebars.
Port (port)Number✅—Connection port (often 5432). Supports Handlebars.
Database (database)String✅—Name of the database.
AuthenticationCredential✅—Direct user/password or Ecosystem credential (BASIC_AUTH).
SQL query (query)String✅—SQL query with Handlebars templating. Use $1, $2, … for the bound parameters.
Binds (binds)List (jsonpath)❌—List of jsonpath expressions evaluated at execution ($.context.userId, etc.).
SSLTLS options❌—TLS options: ca, key, cert, rejectUnauthorized.
Timeout (timeoutSeconds)Number (seconds)❌30Maximum delay in seconds (default 30, max 300).
Output key (outputKey)String❌postgresqlResultContext key for the result.
Stop the workflow on failureBoolean❌trueWorkflow stop in case of SQL or connection error.

Query and bound parameters​

The dynamic values are injected via positional binds:

SELECT * FROM users WHERE id = $1 AND status = $2
Parameterized queries and secrets

Always use binds ($1, $2, …) rather than concatenating values in the SQL, and store the passwords in dictionaries or authentication methods. Adjust timeoutSeconds for heavy queries or nightly batches.

Input​

The node receives the workflow context values via positional binds ($1, $2, …) evaluated at execution, and Handlebars templating in the query:

{
  "binds": ["$.context.userId", "$.context.status"]
}

The "falsy" values (0, false, '', null) are kept as they are.

Output​

The result is stored in context.<outputKey>:

PropertyDescription
rowsRows returned by the query
rowCountNumber of affected rows
commandType of SQL command executed
fieldsColumn names

Example of result for outputKey: "postgresqlResult":

{
  "postgresqlResult": {
    "rows": [
      { "id": 1, "email": "user1@example.com", "created_at": "2023-01-01" },
      { "id": 2, "email": "user2@example.com", "created_at": "2023-01-02" }
    ],
    "rowCount": 2,
    "command": "SELECT",
    "fields": ["id", "email", "created_at"]
  }
}

The result is consumable in the following nodes via {{postgresqlResult.rows}}, {{postgresqlResult.rowCount}}, or {{postgresqlResult.rows[0].email}} — for example in a Send an email node or a ForEach loop that iterates over rows.

Errors​

In case of SQL or connection error, the node fails and stops the workflow execution (option Stop the workflow on failure, default true). To handle the failure cleanly, add an On Error node to the workflow.

See also: Best practices — Error management.

Limits​

  • Maximum timeout of 300 seconds (default 30).
  • Adjust timeoutSeconds for heavy queries or nightly batches.

Example​

Read users and use them in the rest of the workflow:

  1. A trigger starts the workflow.
  2. The PostgreSQL node executes SELECT * FROM users WHERE id = $1 AND status = $2 with the binds $.context.userId and $.context.status.
  3. The result is available via {{postgresqlResult.rows}} — for example a ForEach loop iterates over rows, or a Send an email node uses {{postgresqlResult.rows[0].email}}.

See also​