Zero-downtime DB scaling playbooks with live orchestration

When a team needs to scale a production database — more memory, a larger instance class, a storage expansion — the right approach to minimize downtime is almost never 'click scale in the console.' It involves sequencing: promote a read replica, point application traffic at it, scale the original, fail back. The problem is that this multi-step orchestration exists nowhere as a tested, runnable procedure specific to the team's actual database configuration. Engineers write it in a Confluence doc, execute it manually step by step under pressure, and still produce 5-10 minutes of downtime because one step takes longer than expected or a connection pool doesn't drain cleanly.

Complaints are direct about this: 'I would like to be able to scale with 0 downtime', 'time for the upgrade of instance types requires downtime, lacking a hot upgrade option', 'changing the underlying infrastructure to upgrade memory or use new instances requires downtime, which should be avoidable.' AWS and Aiven don't offer this orchestration because it's genuinely hard — it requires understanding the application's connection behavior, not just the database. That's the structural reason this gap persists: the managed DB vendor controls the database layer but not the application layer, so they can't safely orchestrate the full sequence.

What engineers currently do instead: schedule a 30-minute maintenance window to cover a 5-minute operation, send internal communications, and accept the operational drag. For teams with SLAs or uptime commitments, this is a recurring cost — every engine upgrade cycle, every scaling event, every instance generation change.

This is clearly a business rather than a feature because the orchestration logic is specific to each team's topology (multi-AZ, read replicas, connection pooler in front, application retry behavior) and changes as the infrastructure evolves. AWS could not ship this as a generic feature without knowing the application layer. But a tool that learns a team's topology once and generates a runnable, version-controlled playbook — and can execute it with approval gates — sits in the gap between the DB console and the application.

What to build

Build a runbook generator and executor that reads a team's RDS or Aurora topology via AWS API, produces a step-by-step scaling or upgrade procedure specific to their replica configuration and connection pooler setup, lets them dry-run it against a staging instance, and executes it in production with per-step approval gates and automatic rollback triggers.

Where to start

Start with the single operation most teams perform on a fixed schedule: major engine version upgrades (e.g., Postgres 14 to 15, MySQL 5.7 end-of-life migrations). This is a predictable event every team faces, the stakes are high enough to justify paying for help, and the sequencing is standardized enough that the playbook generator can be accurate before you've solved the harder general case.

The hard part

The tool needs to understand application-layer behavior (connection pool drain time, retry logic, DNS TTL) to generate an accurate playbook, but it can't read the application — so the first version will require manual input for those parameters, which creates friction during onboarding and risks producing playbooks that look credible but fail in practice.

How it makes money

Charge per playbook execution for production operations, with a lower monthly fee for unlimited staging dry-runs — aligning cost with the moments of highest value and making the pricing easy to justify as insurance against a single bad upgrade.