Engineering field study · Aurora PostgreSQL · In progress
Agentic database reliability: beyond a successful tool call.
A hands-on reconstruction and critical investigation of AI-assisted database operations: from a disposable Terraform lab to observable, policy-governed remediation.
Aurora PostgreSQL 16TerraformAmazon Bedrock + StrandsSynthetic workloadNot production qualified
Research question
Can an autonomous agent improve a database, not merely change it?
Generic language-model knowledge is not enough to manage a particular database safely. The system must observe that database, understand its workload and previous decisions, propose bounded changes, and compare results against a meaningful baseline.
Engineering record
01 / Infrastructure
Reconstruct the missing environment
Built a Terraform-managed AWS lab around Aurora PostgreSQL, VPC networking, SSM access, IAM, observability, and teardown. The latest teardown reported 42 resources destroyed; publication of the reproducible implementation is in progress.
02 / Discovery
Use an LLM to select an infrastructure tool
A Strands discovery agent called the RDS API and correctly identified the laboratory Aurora cluster, its PostgreSQL engine, endpoints, and database.
03 / Diagnosis
Inspect actual database performance data
The health agent queried Aurora SQL statistics and summarized expensive bulk loads and index-building statements. This verified the diagnostic path, not a sustained application-performance root cause.
04 / Action
Perform a database change and question the result
The action agent reported creating a concurrent index on projects.proj_name. We also found an existing composite index beginning with proj_name, raising a redundancy question the agent did not resolve before acting.
05 / Qualification
Run a controlled supervisor experiment
A final continuous-workload test, autonomous root-cause investigation, remediation, and before/after measurement remain outstanding. No proven performance improvement is claimed yet.
What the lab established
Working components, with bounded conclusions.
- A disposable Aurora environment deployed and destroyed through Terraform.
- A working Bedrock/Strands tool invocation against AWS RDS.
- A diagnostic tool querying Aurora database statistics.
- A concurrent index creation invoked by a database-action agent.
- A documented route from workshop reproduction to independent engineering research.
Not yet demonstrated
Claims still requiring evidence.
- Repeatable, measured before/after recovery under the same running workload.
- Complete supervisor-agent remediation and independent verification.
- Production-safe permissions, approvals, and rollback behavior.
- Persistent cluster-specific incident memory and baseline learning.
- An audited, publicly reproducible and appropriately licensed code repository.
Technical findings
01Finding
Tool invocation is not operational intelligence.
The initial health agent depended on predefined SQL against PostgreSQL catalogs and statistics. An LLM chose which tool to call; it did not independently discover the diagnostic method.
02Finding
Successful DDL is not successful remediation.
The action agent's index creation was a functional demonstration, but we did not establish that the new index improved the workload. Existing overlapping indexes and write overhead must enter the decision.
03Finding
Safety needs enforceable boundaries.
CREATE INDEX CONCURRENTLY reduces blocking compared with a regular index build, but it can still wait, consume resources, and introduce operational risk. Prompt instructions and keyword scans are not sufficient change controls.
04Finding
Learning requires durable evidence.
A future system should remember cluster-specific baselines, prior incidents, rejected hypotheses, and observed outcomes, then verify recovery instead of reporting success when a tool returns successfully.
Provenance and next steps
Inspired by AWS DAT302; independently assessed.
This field study was inspired by the AWS re:Invent 2025 DAT302 builders' session on autonomous DBOps. It is an independent DBRE.tech investigation, not an AWS publication or an endorsement. The companion implementation is being prepared as a separate repository, with a licensing review of training materials before any source is redistributed.
Next: complete the supervisor benchmark; publish the audited Terraform and independently authored agent implementation; strengthen change gates and before/after verification; and compare against AWS DevOps Agent in a follow-on study.