Which databases does it support?

Amazon RDS and Aurora for PostgreSQL and MySQL, using the metrics, logs and Performance Insights data you already collect.

Will agents run queries against production?

Only read-only diagnostic queries, scoped to the databases you connect. Any change, such as a new index, runs only at the approval level you set.

Does it replace our DBAs?

No. Agents take the first investigation and the routine fixes. Your DBAs keep the decisions and spend more time on schema design and capacity planning.

How are risky changes handled?

Every proposed change comes with its evidence and a rollback plan. Schema and parameter changes go through approval, and every action is logged.

AWS Partner

SOC 2 Reports

Frontier Resolutionfor Database Reliability

Slow queries, locks and capacity issues found and fixed.

Connect your RDS and Aurora fleet read-only. Agents watch query performance, locks, replication and storage, trace a slowdown to the query, plan or change behind it, and hand your team a tested fix ready to approve. Your DBAs stop firefighting and start planning.

Book a Demo See how it works

Performance Insightsroot cause found

orders-db load above vCPU count for 12 min

Signals: DB load 14 on 8 vCPU, top wait IO:DataFileRead
Query: Report query scans 38M rows on invoices
Root cause: Plan switched to a sequential scan after stats went stale
Evidence: Plan diff, wait events and table stats
Fix: Run ANALYZE on invoices, add a partial index. Reversible

Investigated in 2m 10s. Waiting for DBA approval

[The work behind every slow query]

Your database slows down in seconds.Finding out why still takes a DBA.

01The manual work

Dig in

Someone pulls up Performance Insights, reads wait events, compares query plans and checks what changed. Usually at the worst possible time.

02The agent handoff

Fix ready

Frontier agents find the query, plan or lock behind the slowdown, attach the evidence and prepare a fix your team can test.

03Your engineers’ role

Approve

Decide which fixes agents may run and which need a DBA. Review the change and choose when it ships.

[Where CloudThinker fits]

Your stack stays.Agents work inside it.

01Databases

Already in production

Amazon RDS and AuroraPerformance Insights and logs
Azure Database for PostgreSQLQuery Store and metrics
Google Cloud SQLQuery Insights and logs
PostgreSQLpg_stat_statements and plans
MySQLSlow query log and schema

Read-only database role

02Monitoring and change

Your system of record

DatadogDatabase monitoring and APM
GrafanaDashboards and alerts
PagerDutyDatabase on-call
GitHub and GitLabMigrations and schema history

Source of truth stays put

03Investigation

CloudThinker

Find the querySlow statements and their plans
Explain the causeStats, locks, indexes or capacity
Check the changeMigration or release behind it
Propose the fixIndex, ANALYZE or config, reversible

Nothing runs without a DBA

04Response

Fixed, then measured

SlackFinding posted to the DBA channel
JiraTicket with plan and evidence
GitHubMigration pull request when needed
PagerDutyIncident closed once latency holds

Fix runs on approval

Logos show common stacks. CloudThinker connects to each database through a read-only role you approve.

[Example scenario]

Month end, 17:05. Finance reports time out.Close is due tomorrow morning.

A fintech team with 2 DBAs supporting an Aurora PostgreSQL cluster and 6 RDS instances. Finance runs month-end reports against orders-db.

17:05
Load spikesSignal
Performance Insights: DB load at 14 on 8 vCPU for 12 minutes. Top wait is IO:DataFileRead.
17:06
Query foundAgent
The month-end report query on invoices now scans 38M rows. Last week it used an index and finished in 4 seconds.
17:07
Root causeAgent
Table stats went stale after a bulk import at 14:00, so the planner switched to a sequential scan.
17:08
Fix testedAgent
Ran ANALYZE and the query on a clone. The plan returns to the index and runtime drops to 3.8s. Proposes the same on production.
17:12
DBA approvesYour team
The DBA reads the plan diff and approves ANALYZE now, and a partial index for the next maintenance window.
17:15
VerifiedAgent
DB load back to 3. Finance reports finish. Follow-up ticket DBA-318 adds a stats check after bulk imports.

#db-oncall4 messages

CloudWatch17:05
ALARM: orders-db DBLoad above 8 for 10 minutes.
CloudThinker17:08
Report query on invoices switched to a seq scan after the 14:00 bulk import left stats stale. Tested on a clone: ANALYZE brings it back to 3.8s. Reversible.
DBA17:12
Approved. Schedule the partial index for Sunday.
CloudThinker17:15
Done. DB load at 3 and falling. Partial index scheduled for Sunday 02:00. DBA-318 opened for a post-import stats check.

from alarm to verified fix: 10 min
row scan traced to one stale table: 38M
evenings lost by the DBA team: 0

An illustrative example. Team, systems and times are representative, not a specific customer.

[Frontier resolution agents]

Every slowdown traced to a cause.Every fix checked before it runs.

Agents work the same signals your DBAs use, so a slowdown arrives with the query, the plan and the change already lined up, and capacity limits show up before they become an outage.

Find the slow query: Top queries, wait events and plan changes pulled together, so the one query that matters stands out.
Untangle locks: Blocking sessions and lock chains traced to the transaction that started them, with a safe way out.
Watch replicas and storage: Replica lag, connection counts and storage growth tracked against the limits you set.
Hand over a tested fix: Index, parameter and query changes proposed with a rollback plan, run only at the approval level you set.

[What changes]

Same team. Same tools.Far less of the work by hand.

Moment	Today	With frontier agents
A slowdown starts	Noticed when users complain	Investigated as soon as load climbs
Finding the cause	A DBA reads plans by hand	Query, plan and change lined up with evidence
Lock contention	Kill sessions and hope	The blocking transaction named, with a safe fix
Capacity	Found when storage or connections run out	Flagged early against your limits
What the team learns	Lives with one or two DBAs	Written into every investigation

[Integrations]

Connects to the rest of your stack.Read-only to start.

Amazon RDS
Amazon Aurora
Performance Insights
Amazon CloudWatch
PostgreSQL
MySQL
Datadog
Grafana
New Relic
PagerDuty
Opsgenie
Slack
GitHub
GitLab

[Adoption path]

One pilot.Then company-wide.

The rollout follows the four phases of the AWS Cloud Adoption Framework, so it fits the plan your cloud team already runs.

01Envision
Pick one busy database
Connect one cluster read-only and let agents investigate in shadow mode. Compare their findings with your DBAs’.
02Align
Agree the autonomy policy
Decide which changes agents may run alone, such as refreshing stats, and which need a DBA to approve.
03Launch
Roll out across the fleet
Add each team’s databases on the same policies, report format and audit trail.
04Scale
Make it the default
New databases launch with investigation on. Findings feed schema reviews, capacity plans and runbooks.

[AWS guidance]

Built the way AWS says to run it.Reviews start from a known reference.

[Trust and control]

Agents do the work.Your team keeps control.

You approve every change: Agents propose. Nothing touches production until someone on your team says yes, and you set that rule per system.
Every action on the record: Each step is logged, attributed and reversible, ready for your auditors.
Certified for enterprise: SOC 2 Type II and ISO 42001, with reports in our trust center.
Runs where you need it: In our cloud, through AWS Marketplace, or inside your own account.

[Questions]

What teams askbefore they start.

Which databases does it support?: Amazon RDS and Aurora for PostgreSQL and MySQL, using the metrics, logs and Performance Insights data you already collect.
Will agents run queries against production?: Only read-only diagnostic queries, scoped to the databases you connect. Any change, such as a new index, runs only at the approval level you set.
Does it replace our DBAs?: No. Agents take the first investigation and the routine fixes. Your DBAs keep the decisions and spend more time on schema design and capacity planning.
How are risky changes handled?: Every proposed change comes with its evidence and a rollback plan. Schema and parameter changes go through approval, and every action is logged.

[Go deeper]