Databases — Postgres & MySQL (v0.28+)
Configure one or more databases via.env and query them from any agent via the db-postgres / db-mysql skills. Same pattern as the social integrations (SOCIAL_YOUTUBE_N_*, etc.) — numbered blocks, .env is gitignored, no extra infra.
TL;DR
Supported flavors (v1)
Mongo and Redis are planned for v2 — same env-block pattern, different verbs.
Env block reference
Postgres
MySQL / MariaDB
How agents pick a connection
- By label (case-insensitive exact match):
query msgops-dev "SELECT ...". - By index (the
Nin the env key):query 1 "SELECT ...". - If the label matches two blocks (user error — labels should be unique), the agent gets an
ambiguouserror and has to use the index.
Commands (same surface across flavors)
Guardrails
- Read-only by default. Write verbs —
DELETE | UPDATE | INSERT | REPLACE | TRUNCATE | DROP | ALTER | CREATE | GRANT | REVOKE | ...— are refused unlessALLOW_WRITE=trueon that specific connection. - One statement per call. Multi-statement SQL (extra
;with content after) is refused in v1. - Timeouts are enforced server-side (
statement_timeoutfor Postgres,MAX_EXECUTION_TIMEfor MySQL 5.7.4+) — a runaway query hits the DB’s own cancellation, not just a client-side timer. - Row cap —
MAX_ROWSis a soft cap on what’s returned inline. When exceeded, the script persists the full result toADWs/logs/db-queries/<query_id>.csvand signalstruncated: true+full_result_pathso the agent can read the file directly instead of re-running with a larger limit. - Credentials stay in
.env. They never transit through the dashboard’s process memory (unless you use the/integrations/databasesTest button, which only reads them transiently for the test RTT), never get logged, and never enter the agent’s context beyond the subprocess that executes the query with those env vars set.
Error codes
Rotating a password
- Edit
.env— replace the old value in the relevant block. - Restart the dashboard (or just source
.envagain in the shell you run agents from). - The next
db_client.pycall reads the new value — no restart of individual agents needed.
FAQ
Why not a SQLite registry + encrypted credentials? We considered it, chose.env for consistency with every other integration (Stripe, Omie, Social) and because it already solves the problem: .env is gitignored, editable in plain text, and there’s an in-product env editor at /integrations/env-editor for dashboard-only flows. Zero new infra, no new master key, no new table.
What about DBs behind Auth0 / OIDC proxies?
v1 assumes a static password or DSN is enough. If a DB requires token-exchange, the current workaround is to set a service token as PASSWORD and let the proxy handle exchange. Native OIDC support is deferred.
Can I use this for the workspace’s own SQLite DB (dashboard.db)?
Not in v1 — the db-* skills target network-attached SQL services. For dashboard.db introspection, keep using data-analyze / data-write-query which already know that shape.
Is the /integrations/databases page the source of truth?
No. .env is. The page is a read-only convenience view — it lists what’s parsed from .env, offers a Test button, and can copy a block template to the clipboard. It never persists passwords.
See also
db-postgresSKILL.md — full command reference + deep-dive referencesdb-mysqlSKILL.md — full command reference + deep-dive referencesdata-write-query— SQL authoring skill (can compose withdb-*via--connection <label>flag — coming in PR 2)- Upstream reference content: planetscale/database-skills (MIT)