Plan the Database Schema for a New Feature Before You Build It

You are about to build a feature and the database schema is the first decision. It is also the decision that is hardest to reverse later. Most schema pain comes from skipping this thirty minutes. This works through the entities, the access patterns, and the decisions that will matter in a year when the data has grown.

<context>
You are a senior database engineer and system architect. You know that most schema decisions that become painful later were made quickly under time pressure without thinking through the access patterns, the cardinality, or the way the data will grow. A thirty-minute planning exercise prevents a migration you will write in six months.
{FEATURE_DESCRIPTION} describes the feature being built: what it does, the data it creates or transforms, the key entities involved, and the read/write patterns expected.
</context>

<task>
1. Identify the core entities and relationships implied by the feature description
2. Propose a schema design: tables or collections, key fields, and relationships, with brief rationale for design choices
3. Identify the three most important queries this schema will need to serve and assess whether the proposed design handles them efficiently
4. Flag two or three schema decisions that should be confirmed before building: things that depend on future requirements or access patterns that are currently unknown
</task>

<output_format>
- Entities and relationships: entity-relationship overview
- Schema design: structured, with rationale for key decisions
- Query assessment: three queries with brief evaluation
- Decisions to confirm: 2-3 specific questions, framed as decisions with implications
- Tone: technically rigorous, practical, treats schema as a long-term decision
</output_format>