'database is locked' error under concurrent writes: gc default considerations for low-traffic Forgejo

This question addresses the optimal default setting for automatic repository garbage collection in Forgejo deployments designed for low-traffic workloads. The goal is to determine whether enabling automatic garbage collection by default yields net storage benefits without introducing unacceptable I/O latency during occasional push or pull‑request activity.

Key constraints include SQLite’s documented limitation of approximately ten simultaneous write operations before the ‘database is locked’ error surfaces, and the fact that garbage collection runs can generate brief but measurable I/O spikes. gc behavior may vary across releases, and repository size growth over extended periods without collection, combined with variability in actual traffic patterns, further complicates a one‑size‑fits‑default approach.

• What is the concurrent write operation threshold at which default gc activation increases 500‑error risk in SQLite‑backed instances?
• What is the typical repository size change over six months with gc enabled versus disabled under low‑traffic push frequencies?
• Can a tiered gc schedule—such as manual initiation after defined push intervals—mitigate I/O spikes while preserving storage efficiency?