Start with the questions the product asks
The guestbook on this site has two important query paths: show the latest public messages and check whether the same provider identity has posted during the last 24 hours. The schema names those facts directly. It stores provider and provider_user_id separately, constrains message length in the database, and records created_at in a sortable format.
That is intentionally less flexible than a generic content table. Stable product rules belong in columns and constraints because the database can protect them regardless of which route writes the row. Prepared statements bind identity and message values separately from the SQL text. Uncertain presentation details can remain nullable or outside the core model until they earn a stronger contract.
Index observed access, not imagined scale
D1 indexes reduce rows scanned when they match common predicates and ordering. The guestbook therefore has one index for the reverse-chronological feed and a compound index beginning with provider and provider_user_id for the posting-window check. Column order matters: a multi-column index only helps subsets that include its leftmost columns.
An index is not a decorative promise that the application will scale. It adds storage and write work, so it should correspond to a query that exists. EXPLAIN QUERY PLAN can verify that SQLite selected the intended index, while D1 result metadata shows the rows read and written by the real operation.
Make schema history executable
D1 migrations are ordered SQL files, which makes each structural decision reviewable and repeatable. I prefer additive changes first: introduce a nullable column or a new table, deploy code that understands both shapes, backfill if needed, then tighten the constraint in a later migration. That keeps application rollout and data rollout from becoming one irreversible event.
Cloudflare allows migration commands to target either a binding or a database name. A binding can be renamed, so using the stable database name is a useful guard when environments have similar configuration. The important habit is to make the target explicit before applying a change.
Choose consistency on purpose
Global read replication can move reads closer to users, but replicas are asynchronous. D1's Sessions API carries a bookmark so later queries can read from a database version at least as current as the one the session has already observed. That is what preserves read-your-own-writes behavior across replicas.
A small guestbook does not need replication merely because the option exists. If geography or read volume makes it useful later, the query boundary is already narrow enough to adopt sessions deliberately. Reversibility comes from visible seams like this—not from leaving the original model vague.