Context
The TARS wiki needs metadata persistence — backlinks, project relationships, search indexing, and eventually cross-PAI knowledge sharing. The question was whether to use flat files, SQLite, or a hosted Postgres instance.
Options Considered
| Option | Pros | Cons |
|---|---|---|
| Flat files only | Zero infrastructure, simple | No relational queries, backlinks are slow |
| SQLite | Fast, local, no setup | Not accessible across machines, no web access |
| Neon Postgres | Serverless, accessible everywhere, relational | Requires network, cost at scale |
| PlanetScale (MySQL) | Branching model | MySQL, not standard Postgres |
Decision
Neon Postgres — serverless Postgres with generous free tier, auto-suspend when idle, accessible from Cloudflare Workers via Hyperdrive.
Rationale
- The wiki needs to be accessible from multiple machines (desktop, laptop, Codespaces). SQLite doesn’t support that.
- Neon’s auto-suspend means near-zero cost for a low-traffic personal wiki.
- Standard Postgres means I can use any Postgres client (Drizzle, pg, etc.) without learning a vendor-specific API.
- Hyperdrive integration means future Cloudflare Worker API endpoints can query it efficiently.
Implementation
Connection string stored in sops: secrets get NEON_DATABASE_URL
Schema defined in ~/cloud/projects/wiki/tools/schema.sql.
Status
activeDatabase created. Schema not yet applied — pending wiki tool build.
Revisit Triggers
- If cost exceeds $5/month → evaluate moving to D1 or SQLite + sync
- If query complexity grows → consider adding Prisma ORM