Operate
Data & Durability
Data persistence model, backup expectations, and what to do if something goes wrong.
Data Persistence
KyroDB persists all vector data to disk using write-ahead logging (WAL) and periodic snapshots. Your data survives process restarts and host reboots. The managed cloud runs automated backups to protect against infrastructure failures.
What Is Protected
| Data | Durability |
|---|---|
| Vectors and metadata | Persisted to disk (WAL + snapshots) |
| Project configuration | Stored in managed database with backups |
| API keys | Stored in managed database (hashed) |
| Usage history and audit logs | Retained in managed database |
Recovery Expectations
- Managed cloud projects recover automatically from routine restarts and infrastructure updates.
- API keys can be rotated and reissued through the console at any time.
- If a project enters a degraded state, contact support for assisted recovery.
Current Limitations
KyroDB is transparent about what the service does and does not offer today:
- No self-serve point-in-time restore (coming in a future release).
- No multi-region failover — projects run in a single region.
- No self-serve project reset flow — resets are support-assisted.
Need Help?
If your project is in a degraded or failed state, contact support through the console. Recovery actions are handled by the KyroDB operations team to ensure data integrity.
Best Practices
- Keep your ingest pipeline idempotent so you can safely re-ingest if needed.
- Store embedding source data (documents, text chunks) separately — KyroDB stores vectors and metadata, not the original source content.
- Monitor your project health in the console dashboard. If the state shows
unknown, do not treat displayed endpoints as reliable until the state resolves.
Next Steps
- Usage & Limits for rate limits and quota behavior.
- Errors for retry guidance on transient failures.