What is a temporary database?

What it is not

• Not an in-memory store: an in-memory structure dies with the process; a temporary database survives across processes, machines, and clients for its whole lifetime.
• Not a mock or fixture: mocks fake persistence for tests; a temporary database is real persistence with an expiry date.
• Not a cache: a cache holds a copy of data that lives elsewhere; a temporary database is the primary home of its data until it expires.
• Related but distinct: ephemeral databases in CI (spun up per test run) and database branching (copy-on-write clones) bound lifetime by pipeline, not by TTL.

Why bounded lifetime is a feature

Most prototype infrastructure outlives the prototype. Abandoned projects accumulate: dashboards, keys, billing surprises, and data nobody remembers storing. A temporary database inverts the default: doing nothing cleans up. That changes behavior upstream - you can create one database per experiment, per demo, per bug reproduction, or per agent task, because creation is free of ceremony and abandonment is free of consequences.

The lifecycle typically has three states: alive (normal reads and writes), frozen (expired but restorable for a grace window, so a suddenly-important prototype is not lost), and deleted. Explicit, visible expiry is what separates a trustworthy temporary database from data loss: clients can query time-to-live and act on it.

Typical uses

• Prototypes and MVPs that need real reads and writes before any architecture decision.
• Hackathons, workshops, and classrooms: one database per team, gone after the event.
• QA bug reproductions: state that documents a bug, then expires with it.
• Demos with live data that should not become a maintenance obligation.
• AI agent working state: scratchpads, task queues, and memory between sessions.

A worked example

TmpState implements the pattern as a service: one curl creates a JSON document database with a 24-hour TTL, the returned capability URL is the only credential, expiry is queryable (__meta), expired databases stay frozen and restorable for 72 hours, and paid extension or subscription converts a database that earned permanence into a permanent one in place. The design point is that temporary is the default and permanence is the deliberate exception, not the reverse.

curl tmpstate.dev
# -> a real database, gone in 24h unless you decide otherwise