ADR-02: No database

Context

Most web applications use a (relational) database (PostgreSQL, SQLite, …) to store metadata, user state, and application data. The question was whether TINO should follow that convention.

Decision

TINO stores all persistent state on the filesystem:

  • Bucket metadata (description, access rules) lives in a .meta.yml file inside the bucket directory.

  • Source files are plain files in the bucket.

  • Fonts and local packages are files in configurable directories.

  • User sessions are signed cookies — no server-side session store.

There is no database process, schema, migration, or connection pool.

Note

The absence of a database is a deliberate design choice, not an oversight. If TINO’s requirements ever outgrow the filesystem, introducing a database would be the natural next step — but that day has not come.

Consequences

Positive

  • Zero dependencies
    Deploy with a single container and a volume — no database process, schema, or connection pool.
  • Simple backup
    Backup and restore are a plain filesystem copy, rsync or similar.
  • Inspectable
    All state is readable and editable with standard tools (cat, git, vim).

Negative

  • No rich querying
    Listing buckets iterates the directory. Acceptable at the scale TINO targets (tens to low hundreds of buckets).
  • Manual write serialisation
    Per-slug write serialisation must be handled in application code (threading locks on BucketService) rather than by the database.
  • No cross-bucket transactions
    Atomic operations spanning multiple buckets are not possible.