Database Incremental Backups
Expand YugabyteDB's Backup Solution to offer more recovery points while using less storage space.
Introduction
When you run a cloud database, backups are non-negotiable. At Yugabyte, developers and small businesses relied on our managed service for peace of mind — but the way we handled backups wasn’t scaling. I led the design of incremental backups, a project that redefined how users managed data safety while balancing performance, cost, and usability.
The Challenge
Before this project, every backup was a full copy of the database cluster.
Slow & disruptive: Large clusters took hours to back up, dragging down performance during the process.
Expensive: Storage ballooned when customers kept multiple full copies.
Bad user experience: The longer the backup, the longer their system ran at degraded performance — exactly what users of a transactional database wanted to avoid.
My Role
Lead Product Designer
Team
Product Manager
5 Engineers
Timeline
Q1 2024
STEP 1
Discover & Define
I kicked off the UX design by meeting with the PM and lead engineers to understand:
Why users needed this feature.
What success looked like from both business and technical perspectives.
Key constraints — for example, restores involving multiple incremental backups would take longer because each change set needed to be reapplied in order.
The insights shaped the design goal to be:
Enable developers to easily discover, understand , and confidently use incremental backups to restore data to their desirable points in time.
STEP 2
Ideate & Design
I identified three critical touchpoints in the backup journey:
Scheduling backups
Old flow: “Back up every X days.”
New flow: Users could now pair infrequent full backups with frequent incremental backups in between.
Viewing backup history
The design challenge here is: Incremental backups are chained to a base full backup. Users needed to see these dependencies to predict restore time. I prototyped two visualization patterns, tested them with users, and selected the one that is the most effective to restore.
Restoring from backups
One of the biggest asks from users was more flexibility — they didn’t always want to restore an entire cluster. Sometimes they only needed a subset of databases. To support that, I leaned on familiar patterns to break down the complexity. I designed the flow as a multi-step process, with a clear object-selection step, so users could pick exactly what they wanted to restore without feeling overwhelmed.
I rethought the entry point. Instead of forcing users to always start from a backup, I allowed them to start from their recovery need — for example, choosing the databases they wanted first, then selecting from the available backups. That small shift aligned the flow much more closely with how people actually approach real recovery scenarios.
STEP 3
Validate
I ran two rounds of usability testing:
Round 1: Tested schedule setup, backup list comprehension, and restore success. Gathered feedback on clarity and ease of use.
Round 2: Validated refinements after iterating on weak points.
STEP 4
Hand Off
I collaborated closely with engineers, using key mockups and interactive prototypes to clearly communicate user flows and interaction patterns, ensuring smooth implementation.
Outcome
Shipped on schedule.
Adoption: 80% of customers enabled incremental backups within 8 weeks.
Support: 0 tickets related to the feature — users discovered and used it without friction.
