# ADR-002 : SQLite + Drizzle plutôt que Postgres

# ADR-002 : SQLite + Drizzle plutôt que Postgres

> _Date : 2026 (initial setup) — Statut : accepté_

## Contexte

Stockage relationnel pour : users, games, questions, feedbacks. Volume attendu : <10K users, <100K questions sur la durée de vie du projet (usage perso + qq invités potentiels).

Options : Postgres (standard, riche), MySQL/MariaDB, SQLite (local, simple).

## Décision

**SQLite** (via `better-sqlite3`) + **Drizzle ORM**.

Raisons :
- **Self-host minimal** : un fichier `.db` dans un volume Unraid, zéro service supplémentaire à monitorer
- **ACID suffisant** : SQLite est ACID et plus que rapide pour ce volume. WAL mode active par défaut.
- **`better-sqlite3` synchrone** : pas de Promise pour chaque query, code plus simple, perfs excellentes (< 1ms par query)
- **Drizzle ORM** : types end-to-end, migrations propres (`drizzle-kit generate` + `migrate`), syntaxe expressive sans magie
- **Zéro pool / latence réseau** : la DB tourne dans le même process que le backend

## Conséquences

### Bonnes
- Stack minimaliste : un container app + Qdrant, c'est tout
- Backup trivial : copier le `.db` (en mode WAL : aussi `.db-shm` et `.db-wal`)
- Migrations rapides à appliquer (single-instance, pas de coordination)
- Tests unitaires faciles : `:memory:` ou tmpdir

### Mauvaises
- **Pas de scaling horizontal** : un seul process écrit. Pour scaler, il faudrait migrer vers Postgres.
- **Pas de réplication** : si le fichier corrompt, restore depuis backup obligatoire.
- **Concurrent writes** : SQLite serialize les writes. Pas un problème sur ce volume, mais à connaître.
- **Pas de full-text search avancé** : SQLite a FTS5 mais on ne l'utilise pas. Le retrieval vectoriel est sur Qdrant.

## Alternative envisagée

- **Postgres** : plus robuste mais demande un container supplémentaire, configuration users/perms, backup pg_dump à scripter, tuning à apprendre. Overkill pour <100K rows.
- **PlanetScale / Neon serverless** : non self-hostable simplement. Et envoyer les données chez un cloud tiers va à l'encontre du principe self-host du projet.

## Migration future possible

Si on doit scaler :
1. Drizzle supporte Postgres natif → migrer le schéma `src/schema.ts` (changer le driver)
2. Migrations SQL traduites manuellement (SQLite et Postgres ont des syntaxes proches mais quelques diffs : `INTEGER PRIMARY KEY AUTOINCREMENT` vs `SERIAL`)
3. Sessions in-memory → table `sessions` dans la même DB
4. Container Postgres + volume + healthcheck dans `docker-compose.yml`

L'effort est borné : Drizzle abstrait l'essentiel. C'est faisable en 1-2 jours quand le besoin se présente.