After 20 years of watching developers fight with local database restores, I realized we were solving the wrong problem. We were trying to make 500GB restores faster, when we should have been asking: Why do we need 500GB in the first place?
For virtually every coding task, we only need the schema, the logic, and a representative slice of data. That realization is why I built Kopi.
The Local Resource Trap
Every developer has been here: You need to code a new feature. You should test it locally. However, you want to test it against actual data, so you download the latest database backup... all 100GB of it!
You try to restore it and 30 minutes later it fails because you ran out of disk space. Or RAM. Or The Gods weren't happy with you that day!
Let's assume it succeeded. Now what? You're now using 63GB of RAM in Docker and 900GB of disk space to test your 4-line code change!
Now scale this up to dozens of developers across your organization.
The "Shared Dev Database" Nightmare
Since local restores are often not an option, teams turn to the dreaded "Shared Dev Database." It seems like a good idea until reality hits:
- Resource Contention: You're blocked because another team is using it.
- The "Slot" Battle: You have to open a ticket with IT just to get a fresh restore, and the next available window is 4 hours from now.
- Lucky Dip: Sometimes you get lucky and no one is using it but what state is the data in?
The Mocking Illusion
So, we resort to mocking. We write elaborate scripts to seed fake data or mock our repositories entirely.
It's fast, but it's dangerous. "It works on my machine" becomes the team motto because your mocks didn't account for that one weird foreign key constraint or data type mismatch that only exists in the real database.
This is the problem I have seen over 20+ years in the enterprise development space and the primary reason I developed Kopi.