Why Lens of Charlie Does Not Have a Database

Lens of Charlie publishes documents. It does not currently coordinate accounts, comments, purchases, or shared mutable state. A database would be possible, but possibility is not a requirement.

The decision to remain static-first is not an argument that databases are heavy or undesirable. It is an attempt to match infrastructure to the state the product actually owns.

The source already has durable identity

Articles and project records live in versioned Markdown. Git preserves change history, review context, and stable paths. Astro validates metadata and produces HTML during the build. For a single-author publication, this workflow already answers who changed what, when it changed, and which version was deployed.

Moving the same content into tables would add an editing API, authentication, migrations, backups, and an export path without improving the current authoring loop.

Discovery can be derived

The Writing index, tag routes, RSS feed, sitemap, related articles, and search metadata are deterministic functions of the content collection. They can be generated at build time:

Generated indexes do not become a second source of truth. A clean build can recreate them.

Static moves cost rather than eliminating it

The build must process the whole relevant corpus. Very large image collections need a separate derivative pipeline and manifest. A publication may eventually need incremental builds, preview environments, or an editor that does not use Git. Static architecture is a trade, not a moral position.

Mutable features have a threshold

A database becomes justified when Lens of Charlie owns meaningful mutable state:

• authenticated drafts edited by multiple people;
• comments or reactions with moderation;
• private reading lists synchronized across devices;
• a CMS workflow that Git can no longer support;
• data whose value depends on transactional updates.

Each feature also creates privacy, abuse, backup, and recovery responsibilities. The threshold is therefore not “a database would make this easier to code.” It is “the product now owns state that cannot be derived safely from source.”

Keep the future boundary visible

Static-first should not make future change impossible. Components consume content through collection and data contracts rather than importing provider SDKs. Photography consumes generated metadata rather than storage internals. If a database arrives later, it should enter behind a boundary with a migration and exit strategy.

For now, the absence of a database is a feature of the problem definition. Lens of Charlie can remain a collection of portable sources that become fast documents, and the architecture can spend its complexity budget where readers actually notice it.