databases

The rule that outranks everything else here

A write you cannot undo needs a backup you have verified. Not "there is a backup job" — a dump file, with today's date, whose size is not zero. Before any DROP, TRUNCATE, DELETE without a WHERE, schema migration or restore: take one, name it, and say where it is. This is the one domain where the mistake is measured in somebody's business rather than in a reinstall.

Connecting without putting a password in an argument

Every client takes a password on the command line and every one of them is wrong here: it lands in the conversation, the transcript and the action log permanently. Use the mechanisms built for this:

• PostgreSQL — ~/.pgpass (mode 0600), or PGPASSWORD set inside a single bash -c you do not echo. Better: peer auth as the right user, run_command "sudo -u postgres psql -c '\\l'".
• MySQL/MariaDB — ~/.my.cnf with a [client] section, mode 0600.
• MongoDB / Redis — a URI in a file the client reads, not on argv.

If none of that is set up, that is an ask_human: have the person configure the credential file, or run the one command that needs it. See the rule in your system prompt.

Reading before writing

• Is it even up? service_control postgresql status, then the port: run_command "ss -tulpn | grep -E '5432|3306|27017|6379'". A database that is running and not listening on the interface you expect is a config problem, not a database problem.
• Can I connect? psql -c 'SELECT 1', mysql -e 'SELECT 1', redis-cli ping, mongosh --eval 'db.runCommand({ping:1})'. One round trip that answers completely beats guessing from a log.
• Where is the data and is there room? A full partition presents as every kind of database error. run_command "df -h" early.

Queries

Non-interactive always — psql -c, mysql -e, mongosh --eval. An interactive client without a TTY hangs waiting for input nobody can send.

Put a LIMIT on anything exploratory. A SELECT * on a large table pulls the whole thing into the conversation and gets spilled to a locator you then have to page through — you paid for the transfer and learned nothing faster. Count first (SELECT count(*)), then look at a slice.

Read a write before you run it. Wrap a destructive statement in a transaction and inspect it: BEGIN; DELETE ...; SELECT count(*) FROM ...; and ROLLBACK unless the number is what you expected. On MySQL check the storage engine first — MyISAM has no transactions, so there is no rollback to reach for.

Dumps and restores are jobs

job_start   pg_dump -Fc mydb -f /tmp/mydb-2026-08-24.dump
job_wait

Then check the artifact: list_directory for a non-zero size, and for a custom-format dump pg_restore -l to prove it is readable. A dump that returned ok and is 0 bytes is the failure this project ranks worst, and it is only discovered when somebody needs it.

mysqldump --single-transaction for InnoDB so the dump is consistent without locking the site. mongodump/mongorestore. Redis persists with BGSAVE and the file is dump.rdb where the config says.

When it will not start

The journal, not the guesses: journalctl -u postgresql -n 100 --no-pager. The four usual causes are a full disk, a permission on the data directory, a port already taken by an old process, and a config file edited with a typo — postgres -C and mysqld --validate-config check the last one without starting anything.