Skip to content

D1 database migration #4767

Description

@JSONbored

Problem: The production D1 database carries the old brand name and cannot be renamed in place. This is the single highest downtime-risk item in the whole rebrand.

Area: Infra / Data

Proposal: Provision a new D1 database, replicate/export-import the data, cut the Worker's database binding over during a declared maintenance window, verify data integrity, then retire the old database after a retention period.

Deliverables:

  • New D1 database live and serving production traffic.
  • A written maintenance-window runbook.
  • A data-integrity verification report (row counts / checksums, pre- and post-migration).

Acceptance criteria:

  • Zero data loss, verified by row-count and checksum comparison.
  • Maintenance-window duration agreed and communicated in advance.

Test scenarios:

  • Dry-run the migration against a staging copy or snapshot before touching production.
  • Verify read and write against the new database before flipping production traffic to it.

Resources:

  • The Worker configuration's database binding.

Boundaries:

  • This is the one step in the entire rebrand that requires an explicitly scheduled maintenance window — do not attempt a live cutover without one.

Part of #4761.

Metadata

Metadata

Assignees

Labels

maintainer-onlyOwner-only work — yields no Gittensor points.roadmapOn the Wave-2 agent-layer roadmap board (project 9)

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions