Database Query
Run a SQL statement against a relational database and capture the result.
What it does
Connects to a database (MySQL, PostgreSQL, SQLite, …), executes one SQL statement, and writes the resulting rows to memory. A later step can iterate over the rows, send them to an AI for analysis, write them to a file, or react conditionally.
The statement supports templating from memory — for example, you can include {{ customer_id }} in the SQL and the platform substitutes the value of the customer_id memory key at runtime.
What you configure
| Field | What it controls | Required | Notes |
|---|---|---|---|
| Client | Database type. | required | mysql, postgres, sqlite, etc. |
| Host | Server address. | required for networked DBs | Leave empty for SQLite. |
| User | Database user. | required for networked DBs | |
| Password | Database password. | required for networked DBs | Stored as a secured value. |
| Database | Database name. | required | |
| SQL statement | The statement to execute. | required | Can read values from memory via {{ key }} placeholders. |
| Result rows (memory output) | Where the rows are stored. | required | An array; each element is a row object. |
| Error message (memory output) | Where to capture the error message if the query fails. | optional | Use a downstream condition to react gracefully to query failures. |
📷 SCREENSHOT: The Database Query step with connection fields collapsed and a SQL statement showing a
{{ memory_key }}placeholder.
Example scenario
Customer lookup. A webhook trigger receives an order ID. A Database Query step looks up the customer associated with the order. The result is then fed to an LLM Prompt that drafts a personalized email, which is sent in the final step.
Recommendations
- ✅ Use a dedicated read-only user for query steps that only need to read. This limits the blast radius if a query goes wrong.
- ✅ Use parameterized SQL (the
{{ key }}placeholders) for any value that comes from outside. The platform escapes them; concatenating raw text invites SQL injection. - ✅ Limit result size with
LIMIT(or the equivalent). Huge result sets bloat memory and slow downstream steps. - ⚠️ Time-zone handling depends on the database client. If you compare dates, store them in UTC.
- ❌ Do not run DDL statements (
DROP,ALTER, …) from this step in production workflows. Reserve schema changes for proper migration tooling. - ❌ Do not embed credentials in the SQL statement. Use the secured fields above.
What to do next
- For event-driven runs based on new rows: Database Listener.
- For sending data to external HTTP APIs: HTTP Request.