本文的驗收標準是：你能從 live app.db 建立 backup，將它還原到隔離路徑，通過 integrity_check 與核心查詢，並記錄 restore duration。

Prepare Source

Prepare source 的核心責任是建立一個有 WAL 與資料變化的 live database。若你已跑過 local file quickstart，可以直接沿用 /tmp/sqlite-lab/app.db。

1mkdir -p /tmp/sqlite-lab/backup /tmp/sqlite-lab/restore
2cd /tmp/sqlite-lab
3sqlite3 app.db "PRAGMA journal_mode = WAL;"
4sqlite3 app.db "INSERT INTO ledger_entries(account_id, amount_cents, idempotency_key, created_at) VALUES (2, 100, 'backup-drill-1', '2026-05-21T01:00:00Z');"

這一步讓 source database 有新的資料。後續會用 backup snapshot 和 source 後續寫入做對照。

Create Backup

Create backup 的核心責任是用 SQLite-aware 方法建立一致 snapshot。SQLite CLI .backup 會透過 SQLite backup API 產出目標檔案。

1sqlite3 app.db ".backup 'backup/app-backup.db'"
2sqlite3 backup/app-backup.db "PRAGMA integrity_check;"

預期 integrity_check 輸出 ok。這是最小 backup evidence。

VACUUM INTO 也可以產出 compact copy，適合想順便整理檔案大小的情境。

1sqlite3 app.db "VACUUM INTO 'backup/app-vacuum-copy.db';"
2sqlite3 backup/app-vacuum-copy.db "PRAGMA integrity_check;"

.backup 與 VACUUM INTO 都要在 runbook 中標明使用條件、耗時、目標路徑與失敗處理。正式環境還要記錄檔案大小、checksum 與 storage retention。

Mutate Source After Backup

Mutate source 的核心責任是確認 backup 是時間點 snapshot。備份後對 source 寫入新資料，再用 restore 驗證 backup 保持原時間點。

1sqlite3 app.db "INSERT INTO ledger_entries(account_id, amount_cents, idempotency_key, created_at) VALUES (1, 777, 'after-backup-write', '2026-05-21T01:05:00Z');"
2sqlite3 app.db "SELECT COUNT(*) FROM ledger_entries;"
3sqlite3 backup/app-backup.db "SELECT COUNT(*) FROM ledger_entries;"

Source count 應比 backup count 多一筆。這個差異讓 RPO 討論具體化：backup 只保護到它建立的時間點。

Restore Isolated Copy

Restore isolated copy 的核心責任是避免把演練和 source 混在一起。把 backup 複製到 restore path，所有 validation 都對 restore file 執行。

 1cp backup/app-backup.db restore/app-restored.db
 2sqlite3 restore/app-restored.db "PRAGMA integrity_check;"
 3sqlite3 restore/app-restored.db <<'SQL'
 4.headers on
 5.mode column
 6SELECT account_id, SUM(amount_cents) AS balance_cents
 7FROM ledger_entries
 8GROUP BY account_id
 9ORDER BY account_id;
10SQL

正式 restore drill 還要啟動 application 指向 restore/app-restored.db，跑核心 read/write smoke test。若 application 需要 migration，也要確認 restore file 的 PRAGMA user_version 與 app version 相容。

RPO / RTO Note

RPO / RTO note 的核心責任是把演練結果轉成服務承諾。RPO 是可接受資料遺失窗口，RTO 是可接受恢復時間。

可以用 shell 的 time 記錄 restore duration。

1time sqlite3 restore/app-restored.db "PRAGMA integrity_check;"

正式服務要把 RPO / RTO 寫進 observability / runbook。

Known Gap

Known gap 的核心責任是讓 lab 結果誠實。這個 drill 驗證 SQLite-aware backup 與 restore path；它尚未覆蓋 object storage credential、remote retention、large database restore time、encrypted disk、user device support flow 與 legal retention。

完成本篇後，下一步可以進入 WAL busy reproduction 觀察 writer boundary，或進入 migration fixture lab 建立 schema change evidence。

本文的驗收標準是：你能從 local SQLite 匯出 schema / seed，匯入 D1 或 Turso preview database，跑相同 query set，記錄 unsupported SQL、latency、error mapping 與 rollback route。

Preview Scope

Preview scope 的核心責任是把 lab 限制在 staging / preview。D1 與 Turso 都是平台產品，實際命令會依 CLI version、帳號、region 與專案設定改變；本文提供操作骨架與 evidence 格式，正式命令以官方文件為準。

官方文件路由：

Preview lab 要先確認資料不含 production PII。若 seed data 來自正式資料，先做 masking 或 synthetic data。

Export Local SQLite

Export local SQLite 的核心責任是建立 target platform 的 seed input。沿用 /tmp/sqlite-lab/app.db 或 migration fixture。

1mkdir -p /tmp/sqlite-edge-lab
2cd /tmp/sqlite-edge-lab
3cp /tmp/sqlite-lab/app.db ./app.db
4sqlite3 app.db ".schema" > schema.sql
5sqlite3 app.db ".dump" > seed.sql
6sqlite3 app.db "SELECT COUNT(*) FROM accounts;"
7sqlite3 app.db "SELECT COUNT(*) FROM ledger_entries;"

schema.sql 用來審查 DDL，seed.sql 用來匯入 preview database。正式 migration 可能要拆 schema / data / index，並處理 target platform limits。

Build Query Matrix

Build query matrix 的核心責任是定義 preview 要驗證什麼。query set 要代表產品行為，而非只跑一個 SELECT 1。

1Q1 list account balances
2Q2 insert ledger entry with unique idempotency key
3Q3 insert duplicate idempotency key and capture error
4Q4 foreign key violation
5Q5 transaction rollback
6Q6 pagination by created_at
7Q7 explain / performance sample if platform supports it

這份 matrix 要保存 expected result。Local SQLite 先跑一次，把 row count、error category、latency baseline 記下來。

1sqlite3 app.db <<'SQL'
2.timer on
3SELECT a.id, a.owner_name, SUM(l.amount_cents) AS balance_cents
4FROM accounts a
5JOIN ledger_entries l ON l.account_id = a.id
6GROUP BY a.id, a.owner_name
7ORDER BY a.id;
8SQL

Import to D1 Preview

Import to D1 preview 的核心責任是驗證 Cloudflare D1 workflow。以下是操作骨架，正式命令與 flags 以 Cloudflare D1 docs 和 Wrangler 版本為準。

1# Example shape only. Use your project naming and official Wrangler docs.
2wrangler d1 create sqlite_edge_preview
3wrangler d1 execute sqlite_edge_preview --file=seed.sql
4wrangler d1 execute sqlite_edge_preview --command="SELECT COUNT(*) FROM accounts;"

D1 preview evidence 要記錄：

若 seed file 太大或某些 SQL 需要改寫，就把 gap 寫進 compatibility matrix，先保留 production migration 的審查邊界。

Import to Turso Preview

Import to Turso preview 的核心責任是驗證 remote database、client SDK 與 embedded replica 行為。以下是操作骨架，正式命令以 Turso docs 與 CLI version 為準。

1# Example shape only. Use your org, group, region and official Turso docs.
2turso db create sqlite-edge-preview
3turso db shell sqlite-edge-preview < seed.sql
4turso db shell sqlite-edge-preview "SELECT COUNT(*) FROM accounts;"

Turso preview evidence 要多記 replica freshness。若使用 embedded replica，測試流程要包含 bootstrap、sync、read query、write delegation 與 sync 後 read。

1embedded replica evidence:
2  bootstrap duration
3  first read latency
4  write path
5  sync command / interval
6  read freshness after write

Freshness 是 product decision。若 query matrix 只測 remote primary，仍需要追加 embedded replica 的使用者體驗驗證。

Compatibility Matrix

Compatibility matrix 的核心責任是把 local SQLite 與 edge target 的差異留下來。建議表格欄位如下：

Decision 欄要寫具體下一步。rewrite workflow 代表 application adapter 要改；split batch 代表 migration runbook 要改；map error 代表 repository error classification 要改。

Latency and Cost Sample

Latency and cost sample 的核心責任是避免只看功能相容。Edge SQLite migration 的收益常來自 region latency 或 managed operation，因此 preview 要量測主要使用者區域的 read / write latency。

最小量測：

1. Local baseline latency。
2. Preview target read latency。
3. Preview target write latency。
4. Error rate / retry count。
5. Estimated request / storage / egress cost。

Latency sample 要搭配 freshness。快速讀到舊資料和稍慢讀到最新資料是不同產品體驗；query matrix 要標註哪個 workflow 可以接受 stale read。

Rollback Route

Rollback route 的核心責任是保留 local SQLite 退路。Preview lab 完成後，要能刪除 preview database、保留 local seed、重跑 local app。

1sqlite3 app.db "PRAGMA integrity_check;"
2sqlite3 app.db "SELECT COUNT(*) FROM accounts;"
3sqlite3 app.db "SELECT COUNT(*) FROM ledger_entries;"

正式 cutover 的 rollback 還要處理 target-only writes。Preview 階段應避免讓真實使用者寫入 target；若需要 shadow traffic，先用 read-only 或 synthetic write。

Completion Note

Completion note 的核心責任是決定是否進入正式 migration。Lab 完成後應輸出四個 artifact：seed.sql、import log、compatibility matrix、rollback note。

進入正式 migration 的條件：

1. Query matrix 主要 workflow 通過或已有 rewrite plan。
2. Platform limits 對資料量與 migration time 可接受。
3. Error mapping 已接到 repository adapter。
4. Freshness / latency 符合產品需求。
5. Export / rollback route 已演練。

完成本篇後，回到 SQLite to D1 / Turso Migration 補正式 phase plan。

本文的驗收標準是：你能建立一個可重建的 app.db，知道它的 schema version、journal mode、foreign key 設定、seed data 與 cleanup 路徑。

Lab Directory

Lab directory 的核心責任是把 SQLite artifact 放在隔離資料夾，避免和正式檔案混淆。以下命令建立一個可刪除的本地工作區。

1mkdir -p /tmp/sqlite-lab
2cd /tmp/sqlite-lab
3rm -f app.db app.db-wal app.db-shm

驗收 artifact 是 /tmp/sqlite-lab/app.db。後續 lab 可以沿用這個路徑，也可以每次從頭建立。

Baseline Schema

Baseline schema 的核心責任是建立一組能測 transaction、constraint、index 與 query 的小型資料模型。這裡使用 accounts 與 ledger_entries，因為它們能清楚展示 foreign key 與金額 invariant。

 1sqlite3 app.db <<'SQL'
 2PRAGMA journal_mode = WAL;
 3PRAGMA foreign_keys = ON;
 4PRAGMA user_version = 1;
 5
 6CREATE TABLE accounts (
 7  id INTEGER PRIMARY KEY,
 8  owner_name TEXT NOT NULL,
 9  status TEXT NOT NULL CHECK (status IN ('active', 'closed')),
10  created_at TEXT NOT NULL
11) STRICT;
12
13CREATE TABLE ledger_entries (
14  id INTEGER PRIMARY KEY,
15  account_id INTEGER NOT NULL REFERENCES accounts(id),
16  amount_cents INTEGER NOT NULL CHECK (amount_cents != 0),
17  idempotency_key TEXT NOT NULL UNIQUE,
18  created_at TEXT NOT NULL
19) STRICT;
20
21CREATE INDEX idx_ledger_entries_account_created
22ON ledger_entries(account_id, created_at);
23SQL

這段 schema 的重點是明確資料合約。STRICT、CHECK、FOREIGN KEY 與 UNIQUE 讓 fixture 更接近正式資料責任，也讓後續 migration lab 有可驗證的 invariant。

Seed Data

Seed data 的核心責任是建立可重跑的測試資料。每筆 ledger entry 都有 idempotency key，讓後續 edge / retry 設計可以沿用。

 1sqlite3 app.db <<'SQL'
 2PRAGMA foreign_keys = ON;
 3
 4BEGIN;
 5INSERT INTO accounts(id, owner_name, status, created_at)
 6VALUES
 7  (1, 'Ada', 'active', '2026-05-21T00:00:00Z'),
 8  (2, 'Lin', 'active', '2026-05-21T00:05:00Z');
 9
10INSERT INTO ledger_entries(account_id, amount_cents, idempotency_key, created_at)
11VALUES
12  (1, 1200, 'seed-ada-credit-1', '2026-05-21T00:10:00Z'),
13  (1, -200, 'seed-ada-debit-1', '2026-05-21T00:12:00Z'),
14  (2, 900, 'seed-lin-credit-1', '2026-05-21T00:15:00Z');
15COMMIT;
16SQL

Seed 完成後先跑基本查詢。這一步確認 schema、constraint 與 index 入口都可用。

1sqlite3 app.db <<'SQL'
2.headers on
3.mode column
4SELECT a.id, a.owner_name, SUM(l.amount_cents) AS balance_cents
5FROM accounts a
6JOIN ledger_entries l ON l.account_id = a.id
7GROUP BY a.id, a.owner_name
8ORDER BY a.id;
9SQL

預期輸出應顯示 Ada 餘額 1000，Lin 餘額 900。

PRAGMA Snapshot

PRAGMA snapshot 的核心責任是把連線設定變成 evidence。SQLite 的部分設定與 connection 有關，因此 lab 要明確查出當前狀態。

1sqlite3 app.db <<'SQL'
2.headers on
3.mode column
4PRAGMA journal_mode;
5PRAGMA foreign_keys;
6PRAGMA user_version;
7PRAGMA integrity_check;
8SQL

驗收重點如下：

Transaction Sample

Transaction sample 的核心責任是建立後續 busy / migration lab 的共同語言。SQLite transaction 成功時要同時更新資料與保護 invariant。

1sqlite3 app.db <<'SQL'
2PRAGMA foreign_keys = ON;
3BEGIN IMMEDIATE;
4INSERT INTO ledger_entries(account_id, amount_cents, idempotency_key, created_at)
5VALUES (1, 300, 'manual-ada-credit-1', '2026-05-21T00:20:00Z');
6COMMIT;
7SQL

BEGIN IMMEDIATE 會提早取得 write lock。這讓後續 WAL busy reproduction 可以直接展示 single writer boundary。

File Artifact Check

File artifact check 的核心責任是讓讀者看到 SQLite 由 .db 與可能存在的 sidecar 共同構成。WAL mode 可能建立 -wal 與 -shm sidecar，backup / copy / restore runbook 要理解這些檔案。

1ls -lh app.db app.db-wal app.db-shm

若 sidecar 暫時未出現，可以再寫入一筆資料或保持連線開啟。Sidecar 是否存在取決於 WAL 狀態、checkpoint 與 connection lifecycle。

Cleanup

Cleanup 的核心責任是讓 lab 可以重跑。若要重新開始，刪除 database 與 sidecar。

1rm -f /tmp/sqlite-lab/app.db /tmp/sqlite-lab/app.db-wal /tmp/sqlite-lab/app.db-shm

完成本篇後，下一步可以進入 backup restore drill 或 WAL busy reproduction。

本文的驗收標準是：你能建立 v1 fixture、套用 v2 migration、產生 v2 snapshot，並用 validation query 證明資料合約仍成立。

Create Fixture

Create fixture 的核心責任是建立乾淨、可重建的 source fixture。沿用 quickstart schema，或重新建立一份 fixture DB。

 1mkdir -p /tmp/sqlite-fixture-lab
 2cd /tmp/sqlite-fixture-lab
 3rm -f fixture-v1.db fixture-v2.db
 4sqlite3 fixture-v1.db <<'SQL'
 5PRAGMA foreign_keys = ON;
 6PRAGMA user_version = 1;
 7
 8CREATE TABLE accounts (
 9  id INTEGER PRIMARY KEY,
10  owner_name TEXT NOT NULL,
11  status TEXT NOT NULL CHECK (status IN ('active', 'closed')),
12  created_at TEXT NOT NULL
13) STRICT;
14
15CREATE TABLE ledger_entries (
16  id INTEGER PRIMARY KEY,
17  account_id INTEGER NOT NULL REFERENCES accounts(id),
18  amount_cents INTEGER NOT NULL CHECK (amount_cents != 0),
19  idempotency_key TEXT NOT NULL UNIQUE,
20  created_at TEXT NOT NULL
21) STRICT;
22
23INSERT INTO accounts VALUES (1, 'Ada', 'active', '2026-05-21T00:00:00Z');
24INSERT INTO ledger_entries(account_id, amount_cents, idempotency_key, created_at)
25VALUES (1, 1000, 'fixture-v1-ada', '2026-05-21T00:10:00Z');
26SQL

這個 fixture 是 v1 source of truth。CI 可以每次從 SQL 重建，也可以保存 fixture-v1.db 作為 binary fixture；兩者都要有版本與 checksum。

Pre-Migration Snapshot

Pre-migration snapshot 的核心責任是建立 rollback 起點。正式 migration 前應先保存 source DB。

1sqlite3 fixture-v1.db ".backup 'fixture-v1-before-migration.db'"
2sqlite3 fixture-v1-before-migration.db "PRAGMA integrity_check;"

這份 snapshot 代表 migration 失敗時的回退點。CI log 要保留 snapshot path、schema version 與 migration id。

Apply Add Column Migration

Apply add column migration 的核心責任是展示低風險 schema change。先複製 v1，再套用 v2。

1cp fixture-v1.db fixture-v2.db
2sqlite3 fixture-v2.db <<'SQL'
3PRAGMA foreign_keys = ON;
4BEGIN;
5ALTER TABLE accounts ADD COLUMN email TEXT;
6PRAGMA user_version = 2;
7COMMIT;
8SQL

驗證 schema version 與新欄位：

1sqlite3 fixture-v2.db <<'SQL'
2PRAGMA user_version;
3PRAGMA table_info(accounts);
4SQL

Add column 是較簡單的 migration。涉及 drop column、rename、constraint 重建或資料 reshape 時，應改用 table rebuild 策略。

Table Rebuild Example

Table rebuild 的核心責任是展示 SQLite schema migration 的高風險路徑。以下範例把 accounts.status 的 allowed value 加入 suspended，透過新表重建 constraint。

 1sqlite3 fixture-v2.db <<'SQL'
 2PRAGMA foreign_keys = OFF;
 3BEGIN;
 4
 5CREATE TABLE accounts_new (
 6  id INTEGER PRIMARY KEY,
 7  owner_name TEXT NOT NULL,
 8  status TEXT NOT NULL CHECK (status IN ('active', 'closed', 'suspended')),
 9  created_at TEXT NOT NULL,
10  email TEXT
11) STRICT;
12
13INSERT INTO accounts_new(id, owner_name, status, created_at, email)
14SELECT id, owner_name, status, created_at, email
15FROM accounts;
16
17DROP TABLE accounts;
18ALTER TABLE accounts_new RENAME TO accounts;
19
20PRAGMA user_version = 3;
21COMMIT;
22PRAGMA foreign_keys = ON;
23SQL

Table rebuild 要保存 index、trigger、view 與 FK reference。這個 lab 只有小型 schema；正式 migration 要先列出所有 dependent object。

Validation Query

Validation query 的核心責任是證明 migration 後資料仍符合 domain invariant。

1sqlite3 fixture-v2.db <<'SQL'
2PRAGMA integrity_check;
3PRAGMA foreign_key_check;
4SELECT COUNT(*) AS account_count FROM accounts;
5SELECT COUNT(*) AS ledger_count FROM ledger_entries;
6SELECT SUM(amount_cents) AS total_balance FROM ledger_entries;
7PRAGMA user_version;
8SQL

驗收結果應包含 integrity ok、foreign key check 空結果、account count 1、ledger count 1、total balance 1000、user version 3。

Contract Test Hook

Contract test hook 的核心責任是讓 fixture 進入 CI。語言與 framework 可以不同，但測試要固定做三件事：開啟 FK、確認 schema version、跑 repository contract。

1test setup:
2  copy fixture-v2.db to temp path
3  open SQLite connection
4  execute PRAGMA foreign_keys = ON
5  assert PRAGMA user_version = 3
6  run repository contract tests

每個 test 使用 temp copy 可以避免資料污染。需要測 concurrency 時，改用 WAL busy reproduction。

Rollback Note

Rollback note 的核心責任是把 migration 失敗時的處理寫清楚。這個 lab 的 rollback 是保留 fixture-v1-before-migration.db，在 migration validation 失敗時停止 release 並保存 failed DB。

正式 runbook 要記錄：

1. Migration id 與 source / target user_version。
2. Pre-migration backup path。
3. Validation query 與結果。
4. Failed DB 保存路徑。
5. Release block / rollback 條件。

完成本篇後，下一步可以讀 SQLite to PostgreSQL migration 或 SQLite to D1 / Turso migration。

本文的驗收標準是：你能用兩個 sqlite3 session 重現 writer contention，觀察 busy timeout 行為，並用 WAL size 與 checkpoint result 連回 production runbook。

Prepare Database

Prepare database 的核心責任是建立可重現的 WAL mode database。若已跑過 local file quickstart，可以沿用 /tmp/sqlite-lab/app.db。

1cd /tmp/sqlite-lab
2sqlite3 app.db "PRAGMA journal_mode = WAL;"
3sqlite3 app.db "PRAGMA busy_timeout = 1000;"

確認 WAL mode：

1sqlite3 app.db "PRAGMA journal_mode;"

預期輸出是 wal。

Session A: Hold Writer Lock

Session A 的核心責任是刻意持有 write transaction。開第一個 terminal，執行：

1sqlite3 app.db

在 sqlite prompt 內輸入：

1PRAGMA foreign_keys = ON;
2BEGIN IMMEDIATE;
3INSERT INTO ledger_entries(account_id, amount_cents, idempotency_key, created_at)
4VALUES (1, 11, 'busy-session-a', '2026-05-21T02:00:00Z');

先保持 transaction 開啟，暫時延後 COMMIT。BEGIN IMMEDIATE 會取得 writer lock，讓第二個 writer 需要等待或失敗。

Session B: Observe Busy

Session B 的核心責任是用第二個 connection 觀察 single writer boundary。開第二個 terminal，執行：

1cd /tmp/sqlite-lab
2sqlite3 app.db "PRAGMA busy_timeout = 1000; INSERT INTO ledger_entries(account_id, amount_cents, idempotency_key, created_at) VALUES (1, 22, 'busy-session-b', '2026-05-21T02:01:00Z');"

預期結果是等待約 1 秒後出現 busy / locked 類錯誤。不同 sqlite3 版本的錯誤文字可能略有差異，核心訊號是第二個 writer 在 Session A commit 前拿不到 write lock。

Release Lock

Release lock 的核心責任是確認 contention 來自 writer transaction。回到 Session A，輸入：

1COMMIT;
2.quit

再次執行 Session B 的 insert，這次應成功。

1sqlite3 app.db "PRAGMA foreign_keys = ON; INSERT INTO ledger_entries(account_id, amount_cents, idempotency_key, created_at) VALUES (1, 22, 'busy-session-b', '2026-05-21T02:01:00Z');"

若 idempotency key 已在前一次嘗試中寫入，改成新的 key。這個細節也提醒 production write 要有 idempotency 設計。

Busy Timeout Comparison

Busy timeout comparison 的核心責任是區分「等一下」和「解決 writer contention」。Timeout 可以讓短暫鎖等待更平滑，但長交易仍會造成延遲或失敗。

重開 Session A 並持有 transaction：

1BEGIN IMMEDIATE;
2INSERT INTO ledger_entries(account_id, amount_cents, idempotency_key, created_at)
3VALUES (1, 33, 'busy-session-a-long', '2026-05-21T02:10:00Z');

在 Session B 測不同 timeout：

1time sqlite3 app.db "PRAGMA busy_timeout = 5000; INSERT INTO ledger_entries(account_id, amount_cents, idempotency_key, created_at) VALUES (1, 44, 'busy-session-b-long', '2026-05-21T02:11:00Z');"

若 Session A 在 5 秒內 commit，Session B 可能成功；若持續持有 transaction，Session B 會在 timeout 後失敗。這就是 production 裡 busy timeout 的邊界：它緩衝短鎖，長 transaction 仍要被設計移除。

WAL and Checkpoint

WAL and checkpoint 的核心責任是把 writer activity 和 file artifact 連起來。多做幾次寫入後觀察 sidecar。

1ls -lh app.db app.db-wal app.db-shm
2sqlite3 app.db "PRAGMA wal_checkpoint(PASSIVE);"

wal_checkpoint 會回傳 checkpoint 狀態。正式 runbook 要記錄 WAL size、checkpoint duration、reader age 與 checkpoint failure。

可以手動觸發 truncate checkpoint：

1sqlite3 app.db "PRAGMA wal_checkpoint(TRUNCATE);"
2ls -lh app.db app.db-wal app.db-shm

TRUNCATE 適合 lab 觀察。Production 使用時要評估 reader、latency 與維護窗口。

Mitigation Note

Mitigation note 的核心責任是把 lab 結果轉成設計策略。看到 SQLITE_BUSY 後，優先檢查 long transaction、未關閉 cursor、背景 job、write burst、parallel test 共用 DB 與 checkpoint pressure。

常見策略包含：

1. 縮短 transaction，將外部 API call 移到 transaction 外。
2. 設定合理 busy timeout 與 retry backoff。
3. 把 write queue 序列化，讓高風險 workflow 先排隊。
4. 將 heavy read 移到 snapshot 或 replica。
5. 當 concurrent writer 成為常態，評估 PostgreSQL / MySQL。

完成本篇後，下一步讀 observability / runbook 把 busy、WAL 與 checkpoint 變成正式監控訊號。