In a world of CI/CD and 10-minute deployment cycles, database provisioning remains the single largest drag on developer velocity.
Kopi was built on a simple premise: setting up a local database should be as fast and
reproducible as npm install.
1. Treating Data like Cattle, not Pets
We learned long ago to treat servers as "cattle": replaceable, automated, and ephemeral. Yet, we still treat our local databases like "pets." We nurture them, we fear wiping them, and we spend hours fixing them when they get sick.
This fear of "wiping the DB" creates a culture of State Drift. Local environments diverge wildly from production reality because the cost of restoration is simply too high. Kopi makes your data disposable again.
2. The "Shared Database" Fallacy
When local restores become impossible, teams pivot to the Shared Development Database. It looks efficient on paper, but it introduces resource contention as a dependency.
- Blocking Dependencies: Team A is running a migration that locks the table Team B needs to query.
- Destructive Testing: You can't test a "Delete User" flow because that user might be part of someone else's active test case.
- The "Who did that?" Loop: Time wasted investigating bugs that turn out to be data changes made by another developer.
3. The Fidelity Gap of Mocks
To avoid the database entirely, we lean on mocking. While essential for unit testing, mocking repositories for integration work creates a dangerous Fidelity Gap.
Mocks validate your logic against your assumptions of the data, not the data itself. They pass in CI but fail in production because they didn't account for a specific foreign key constraint, a trigger side-effect, or a data type mismatch.
We built Kopi to close this gap. It treats data like code: defined, versioned, and ephemeral. It gives you the fidelity of production with the agility of a seed script.