Observe before acting.
Compare intended, configured, attached, and effective database state. Missing evidence is not compliance.
DBRE.tech · Database reliability extension · Draft v0.1
The Agentic DBRE Manifesto.
A database is not a prompt response. It has state, dependencies, durability requirements, and consequences that persist after the agent exits.
Alex Ivanov · DBRE.tech
We favor observable truth over generated certainty, bounded change over expansive autonomy, and demonstrated recovery over optimistic assurances.
This is a specialized application of the Agentic Engineering Manifesto. It describes how we propose to engineer database automation; it does not claim that DBRE.tech has deployed an autonomous production database operator.
Our commitments
Eight obligations before autonomy.
The cost of a database mistake is not measured in tokens. Every principle below can be turned into a test, a policy, an operating procedure, or a measured recovery exercise.
Know the complete blast radius.
Identify all consumers of a shared parameter group, endpoint, credential, schema, or replication topology before changing it.
Make production authority explicit.
A recommendation, a pull request, and permission to mutate production are distinct. Human-approved boundaries remain enforceable outside the model.
Prefer reviewable changes.
For infrastructure-as-code-owned resources, propose versioned changes through the existing pipeline. Do not quietly create configuration drift.
Practice failure before delegating recovery.
Exercise timeouts, stale inventory, failed migrations, retry storms, partial changes, failovers, and recovery procedures in safe environments.
Prove recovery, not just backup completion.
Restore rehearsals and measured RTO/RPO show what the operation can actually deliver.
Make success measurable at the database.
An API success, new execution plan, or completed job is not proof that the intended operational outcome occurred.
Keep autonomous action narrow and reversible.
Start with read-only investigation and reviewed recommendations. Allow consequential execution only when verification, scope and recovery controls warrant it.
A falsifiable example
One parameter group. More than one possible victim.
A proposed Aurora PostgreSQL parameter correction appears scoped to one cluster. Before any execution, the workflow must identify all clusters and instances attached to the relevant parameter group, detect infrastructure-as-code ownership, distinguish dynamic values from pending-reboot settings, and bind approval to the exact target set.
If the inventory is incomplete, the group is unexpectedly shared, or the effective setting cannot be verified, the correct result is a flagged unknown or denied change. A confident agent explanation cannot override that condition.
Read the test-first engineering guide →INVENTORYBLAST RADIUSPOLICY + APPROVALCONTROLLED ACTIONEFFECTIVE STATE
Not an autonomy contest
Useful automation can stop at a recommendation.
An agent that reliably identifies drift, collects relevant evidence, generates a bounded pull request, and verifies the result can create substantial operational value without holding production write credentials.
We should expand authority only after repeatable tests and operational evidence justify doing so—not because a demonstration appeared convincing.