Source-side control
Place the worker near production MySQL, MariaDB, or Percona when source access is tightly controlled and outbound movement is preferred.
Database Recovery Control Plane
Cupcake DRCP turns replication, CDC, migration, comparison, repair, and recovery into one operator-facing surface for teams that need proof before they trust a database move.
Adaptive Deployment Patterns
Cupcake DRCP can sit close to the source, close to the recovery target, or in a central operations hub. The control plane stays consistent while the footprint adapts to network boundaries, customer security rules, and recovery architecture.
Place the worker near production MySQL, MariaDB, or Percona when source access is tightly controlled and outbound movement is preferred.
Put Cupcake next to the DR or migration target so recovery teams can validate lag, compare data, and execute repair from the destination environment.
Use one Cupcake hub to coordinate multiple projects, recurring compare schedules, CDC stream monitoring, and recovery evidence across environments.
Pipeline Visualization
MySQL-compatible sources, mapping policy, snapshot, CDC catch-up, compare, repair, and a target that can be trusted.
The Pain
Show the state of every migration, mirror, comparison, and recovery action from one page.
Turn repeatable workflows into managed jobs with clear policies, checkpoints, and status.
Keep comparison results, repair actions, schedule history, and operational decisions traceable.
The Story
Register MySQL and MariaDB endpoints, validate access, and discover schemas.
Define source-to-target table policy, filters, and migration behavior.
Run snapshot, sync, CDC, and migration jobs with lifecycle controls.
Compare data, inspect drift, and prove the target matches expectations.
Repair differences, schedule repeatable runs, and preserve audit history.
Operations Dashboard
Cupcake’s operations view is built around the questions operators ask during live data movement: is the stream polling, how stale is the heartbeat, what changed in the last hour, where is the binlog position, and should compare/repair be scheduled before cutover?
A live view of database changes.
CDC Monitor
Focus on whether the stream is healthy, caught up, and moving data. Technical events stay available when needed.
Stream Fleet
Mapping for sample_app · redacted runtime
Source: source-host-redacted
Target: target-host-redacted
Job Type: CDC
Heartbeat 11s ago
QPS 14.6/s
Buffer 100.0%
Binlog enabled
| When | Table | Creates | Updates | Deletes | Outcome | Result |
|---|---|---|---|---|---|---|
| 2026-05-08 21:11:42 | - | 0 | 0 | 0 | completed | CDC cycle completed |
| 2026-05-08 21:11:42 | - | 0 | 0 | 0 | n/a | CDC stream heartbeat |
| 2026-05-08 21:11:42 | - | - | - | - | n/a | CDC checkpoint updated |
| 2026-05-08 21:11:37 | - | - | - | - | n/a | CDC binlog cycle found no new events |
| 2026-05-08 21:11:32 | - | 0 | 0 | 0 | completed | CDC cycle completed |
What You Can Sell
One place to plan, start, stop, inspect, and govern replication jobs.
Live event counts, heartbeat age, stream lag, and table-level application signals.
Validation, pause/resume, bulk load controls, and intentional cutover states.
Surface row-level drift between source and target before customers feel it.
Apply scoped reconciliation instead of rerunning fragile, expensive jobs.
Schedule recurring operations and keep queue, run, and outcome evidence in view.
Platform Roadmap
The roadmap should say the quiet part clearly: Cupcake is already strong for MySQL-compatible replication and recovery, and the next platform moves broaden database support while keeping the same workflow for mapping, CDC, compare, repair, automation, and audit evidence.
MySQL, MariaDB, and Percona support for projects, mappings, snapshots, CDC streams, comparison, targeted repair, schedules, and migration workflows.
PostgreSQL endpoints enter the same control plane model: connection discovery, table mapping, movement orchestration, and health visibility.
Additional database connectors will expand recovery and migration coverage while preserving Cupcake’s operator-first workflow.
Deeper schema-change policy, alert routing, richer audit exports, recovery runbooks, and historical health reporting for compliance-ready operations.
The Close
Cupcake DRCP gives database, platform, and recovery teams a shared source of truth for data movement operations that are too important to manage by memory.
FAQs
Cupcake currently focuses on MySQL-compatible operations: MySQL, MariaDB, and Percona.
No. Cupcake supports ongoing replication visibility, CDC monitoring, comparison, repair, scheduling, migration workflows, and recovery evidence.
PostgreSQL support is next on the roadmap, followed by more engines and deeper platform features such as alerting, policies, and audit exports.
Contact
Bring the source, target, timing pressure, and the workflows you need to prove. Cupcake can be positioned around a migration, recovery drill, CDC monitoring rollout, or repeatable compare and repair process.