Querying a database for analysis

You want to understand patterns in a database — "which users went silent in the last 30 days?", "which route has the most errors?". This workspace wires the agent up with safe reads — no chance of DROP TABLE.

Nodes on the canvas

Node	Role
Env pointing at .env.production	Holds the DATABASE_URL for production (a read-only replica, ideally).
Database with a Postgres/MySQL/SQLite/Mongo driver	The real connection.
Agent Terminal	Asks questions in natural language.
JSON (named "Last result")	Each successful query becomes a queryable JSON.
Text (named "Findings")	Where the agent compiles the discoveries.

Connections

From → To	Kind	What it does
Env → Database	manual	Database reads DATABASE_URL from Env.
Agent Terminal → Database	permission db-read-query	Agent runs SELECT, EXPLAIN, sample, count. Never writes.
Database → JSON	port ports:lastResult->setJson	Each query result shows up as JSON.
Database → Text	port ports:lastResultMarkdown->setContent	Result becomes a markdown table in the text (report mode).
Agent Terminal → Text	permission summary	Agent writes formatted findings.

Permissions — why db-read-query instead of db-full-access

The difference is exactly that:

Connector	Can write?	Can SELECT?
db-read-query	No	Yes
db-full-access	Yes	Yes

For analysis, always the read-only one. Even if the agent "thinks it's a good idea" to run an UPDATE, it can't.

You also get db-list-tables, db-describe-table, db-explain, db-sample-rows, db-count-rows — all read-only. See Connector list.

Prompt

Using the Database (wired to a Postgres prod read-replica), answer:

1. How many active users have we had per day in the last 30 days?
2. What's the peak day, the trough day?
3. Which routes in `request_logs` show up most often with status >= 500
   over the last 24h?
4. For each one, what's the most common status code and the most common
   error message (use SUBSTRING if messages are long).

Before each new query, EXPLAIN it — if the cost looks heavy, stop and
ask me before running.

Compile the findings into the "Findings" text node, with a markdown
table and one sentence of interpretation per block.

Why this setup is safe

• Env isolates the URL — you swap prod for staging by editing the .env. The workspace doesn't change.
• db-read-query is the ceiling. Even with a hallucinating agent, there's no path to writes.
• EXPLAIN in the prompt forces the agent to think before scanning 100M rows.
• JSON with lastResult lets you inspect the raw result if you don't trust the agent's interpretation.

Variations

• Mongo: switch the Database driver (source.kind: url, driver: mongodb). Everything else identical; the agent understands the syntax.
• Multiple databases: add more Database nodes, each with its own Env. Wire all to the Agent Terminal — it becomes a multi-source data analyst.
• No replica: if you only have prod with writes, don't use this in prod. Spin up a read replica first.