---
id: 8028aeb5-d922-49aa-b0e6-fbc1cce35484
type: fix
title: "Fix: Document SQLite synchronous=0 pragma in paper-dynasty-database"
tags: [paper-dynasty, sqlite, peewee, documentation, fix, python, db_engine]
importance: 0.5
confidence: 0.8
created: "2026-03-04T01:32:49.610296+00:00"
updated: "2026-03-04T01:32:51.174263+00:00"
relations:
  - target: 04e57a23-0a20-49d6-8c5a-2fa5fc4e55b5
    type: RELATED_TO
    direction: outgoing
    strength: 0.72
    edge_id: 776cac00-9382-4283-a294-392d70259109
  - target: d36a86f0-8183-4c94-8d63-0be65d3fd63a
    type: RELATED_TO
    direction: outgoing
    strength: 0.71
    edge_id: 3aad9a04-dea1-4cf9-9c2d-51b794ee83df
  - target: 5ae1bf6e-1e1c-4486-8a4d-10afd9e42189
    type: RELATED_TO
    direction: outgoing
    strength: 0.71
    edge_id: 029ebb20-fd95-4b65-856b-e5492a6a755c
---

## Problem
`app/db_engine.py:36` had `pragmas={"synchronous": 0}` with no explanation. `synchronous=0` (OFF) skips fsync on writes — fast but risks DB corruption on hard crash.

## Context
- SQLite branch is **dev-only**; production uses PostgreSQL (`DATABASE_TYPE` env var)
- WAL journal mode (`journal_mode=wal`) partially mitigates the corruption window
- Trade-off is acceptable in dev (data loss tolerable, write speed prioritised)

## Solution
Added a block comment above the SQLite `SqliteDatabase(...)` call explaining:
- `synchronous=0` behaviour and crash-corruption risk
- Why it's acceptable in dev (not used in production)
- How WAL mode reduces (but doesn't eliminate) the risk

## Files Changed
- `app/db_engine.py` — comment at SQLite branch (line ~33)

## PR
https://git.manticorum.com/cal/paper-dynasty-database/pulls/49 (issue #20)