Add a SQLite storage backend, with bulk import/export

[jdtw]

Why

The link database is a single three-column table:

create table if not exists links (
  path text primary key,
  link text not null,
  segments int not null
);

That does not need a managed Postgres instance behind it. This adds a SQLite backend so the table can live in a file on a small volume instead, which suits a low-traffic personal redirector. Postgres stays supported as the fallback.

What

SQLite store implementing the existing Store interface, so the choice is a deployment detail rather than a rewrite.

• Driver is modernc.org/sqlite, not mattn/go-sqlite3 — the Dockerfile builds CGO_ENABLED=0 into distroless/static, so a cgo driver would not link.
• WAL mode so redirect reads don't block on writes; schema applied on open so a fresh volume needs no setup.
• Put reports created-vs-updated via a transaction, since SQLite has no equivalent of the Postgres xmax = 0 trick.
• Precedence: --ephemeral, then SQLITE_PATH, then DATABASE_URL. Unsetting one variable reverts to Postgres.

The tradeoff: a file on a volume pins the app to one machine in one region, with no replication. Fine for this workload.

Bulk import/export. GET /api/links already returned everything; this adds POST /api/links plus --export / --import client flags. Imports are additive (a restore can't silently drop links) and fully validated before the first write (one bad URI fails the request rather than half-applying). The validation put() did inline moved to validateLink so single and bulk writes can't drift.

That makes moving between backends: export, restart with SQLITE_PATH set against an empty file, import. No direct database access required. It doubles as an ordinary backup/restore path.

Testing

Beyond unit tests, the switch was rehearsed locally end to end: server on real Postgres in Docker → export via the REST API → second server on an empty SQLite file (verified 0 links, /rfc/5280 → 404) → import →

/rfc/5280   → 302 https://datatracker.ietf.org/doc/html/rfc5280
/swap/a/b   → 302 https://example.com/b/a
/plain      → 302 https://example.com/plain
/(root)     → 302 https://jdtw.us/

The .index root redirect and {1}/{0} substitution both survive. Re-importing is idempotent, and exporting back out of SQLite diffs identical to the original Postgres export.

Also verified: the production Docker image builds and runs with the pure-Go driver, data survives a container restart on a mounted volume, and test.sh passes against both backends (./sqlite_test.sh and ./docker_test.sh) — the latter being the CI configuration.

15 new tests.

Not included

fly.toml is unchanged. Setting SQLITE_PATH there would switch storage on the next deploy, before any data exists — every link would 404. Provisioning the volume and adding a [[mounts]] block is a separate deliberate step.

A direct Postgres-to-SQLite cmd/migrate tool was written and then removed in ca655d3 — the REST path covers it, and shipping the extra binary took the image from ~42MB to ~75MB. It's in the branch history if it's ever wanted.

🤖 Generated with Claude Code