Does the database optimization workflow make production changes automatically?

No. The workflow is evidence-first and human-reviewed. It does not automatically create indexes, rewrite SQL, update rows, change configuration, or write to production databases.

What happens before recommendations are made?

The process starts with the visible symptom, then gathers safe evidence, narrows scope, and puts findings through review before recommendations are written.

Does this page save user database data?

No. This static page does not provide uploads, accounts, hosted collector storage, or report storage, so it does not save user database content, credentials, queries, files, or customer data. PostgreSQL specialist workflows are downstream paths with their own evidence-sharing rules.

Where should PostgreSQL teams go after reading this workflow?

PostgreSQL teams can use the broad workflow for orientation, then continue into the PostgreSQL path when they need the current specialist collector and report workflow.

How it works

Database optimization should move from symptom to approved next step, not straight to production changes.

This workflow explains how a broad database optimization audit turns a slow workflow, timeout, cost spike, or capacity concern into evidence, scope, review, recommendations, and a human-approved action plan.

Start audit scope Prepare the checklist

Process

The audit path has six gates

Each gate narrows uncertainty before anyone treats a recommendation as production-ready.

Symptom

Name the user-visible problem: slow checkout, dashboard timeouts, batch lag, lock waits, cloud cost pressure, or recurring incident risk.

Evidence

Collect safe signals such as slow query examples, plans, query statistics, index context, table sizes, wait notes, hosting limits, and recent deploy history.

Scope

Separate the likely database problem from application code, infrastructure, data growth, release timing, and business constraints that shape the review.

Review

A human reviewer checks the evidence, confidence level, missing context, production risk, and whether PostgreSQL should enter the specialist path.

Recommendation

The output is a ranked set of next steps: deeper evidence, staging tests, query rewrites, index candidates, maintenance checks, or configuration review points.

Approval

Production work waits for your owner, test plan, rollback path, maintenance window, and explicit approval. The audit does not approve itself.

Boundaries

What stays outside the automatic path

The site is meant to support safer decisions, not become an unrestricted database operator.

Boundary	What it means
Read-only first	The first step should use metadata, statistics, query plans, logs, and sanitized examples. Broad production write access is not required for scoping.
Human review	Findings are reviewed before recommendations are treated as useful. Confidence, impact, reversibility, and missing evidence are part of the decision.
No automatic production writes	The workflow does not create indexes, rewrite deployed SQL, update data, run migrations, change configuration, or schedule maintenance automatically.
No hosted storage on this page	This static page does not provide uploads, accounts, hosted collector storage, or report storage, so it does not save user database content, credentials, queries, files, or customer data. PostgreSQL specialist workflows are downstream paths with their own evidence-sharing rules.
Approval required	Any index, SQL, configuration, vacuum, migration, or rollout action belongs to your team's approval and change-management process.

Need the access details first?

Review the read-only database audit boundary before sharing evidence, credentials, or production context.

Where to go

Use the right next page for your stage

The workflow is broad by design. It helps MySQL, SQL Server, PostgreSQL, and other database teams frame the same decision path without claiming every engine has a formal service workflow here today.

When the problem is audit-ready

Use the audit page to turn symptom, evidence, scope, and safety limits into a clear request for review.

Open database optimization audit

When evidence is scattered

Use the checklist to prepare the business symptom, database context, query evidence, safety constraints, and approval path.

Open preparation checklist

When deliverables are unclear

Use the sample report to see how evidence, findings, risk notes, recommendations, and approval boundaries should be presented.

Open sample report

PostgreSQL routing

PostgreSQL can move into the specialist path

If your evidence points to PostgreSQL, use this broad workflow to frame the issue, then continue into the PostgreSQL pages for the current specialist collector and sample report path.

Use broad framing first

Describe the symptom, share safe evidence, define production boundaries, and confirm who approves any database change.

Then enter PostgreSQL scope

Move to PostgreSQL when the engine, evidence, and next step fit that specialist route instead of a generic database optimization explanation.

Ready to choose the path?

Start with the broad audit scope, prepare inputs with the checklist, or compare expectations against the sample report. PostgreSQL teams can continue to the PostgreSQL audit hub.