Choose a Database From Real Access Patterns

The boring database usually wins because its guarantees and failure modes match the product, not because SQL or documents are universally better. Start with the reads, writes, and transactions you must support.

This guide belongs to reel R102. Comment SQLPICK for the matching module and runnable starter.

Define the boundary before building

Input: entities, relationships, query examples, transaction boundaries, consistency needs, scale estimates, operational constraints, and team experience.

Output: an access-pattern map, relational and document tradeoffs, rejected options, proof queries, risk register, and decision record.

The starter keeps exact checks in code and gives Claude only the reviewable drafting work. Dry-run is the default. Live mode can call Anthropic's Messages API, but it still returns a draft and performs no external action.

Paste this boundary into Claude Code before asking for implementation:

Workflow: Choose a Database From Real Access Patterns
Input: entities, relationships, query examples, transaction boundaries, consistency needs, scale estimates, operational constraints, and team experience
Output: an access-pattern map, relational and document tradeoffs, rejected options, proof queries, risk register, and decision record

Map the trigger, strict input fields, deterministic code checks, Claude drafting step, approval gate, failure queue, and saved evidence. Use null for missing facts. Do not change code or call an external service yet.

The modules that matter

Map access patterns

Write representative reads and writes with expected volume, latency, filtering, ordering, and relationship depth. Mark which operations must commit together.

Compare the real tradeoffs

Score relational and document options on query fit, consistency, schema change, indexing, backup and restore, observability, hosting, and team experience. Record rejected choices.

Prototype the hard part

Build the two hardest reads and one important transaction with representative fictional data. Inspect the query plan and failure behaviour. Rehearse restore before calling an option operationally simple.

Rules worth keeping beside the code

Start with reads, writes, relationships, and consistency requirements.
Use real query examples instead of product category slogans.
Include migrations, backups, observability, and team operations in the decision.
Test the riskiest query before choosing a database.

The dangerous version is choosing from hype, ignoring transactions, assuming scale without estimates, or selecting a database the team cannot restore and operate. The pack deliberately stops at a draft so a person can inspect those boundaries before enabling anything real.

Test the ugly paths

Core transaction is atomic.
Hard reads meet the target on representative data.
Consistency model matches the user outcome.
Backup and restore are documented.
Team can inspect and repair a failed operation.

The final verification is concrete: Prototype the two hardest reads and one transaction with representative data, then rehearse backup and restore before signing the decision record.

Use this prompt to turn the evidence into acceptance tests:

Design tests for Choose a Database From Real Access Patterns using only the attached fictional fixtures.
Cover the normal path, missing input, malformed input, a repeated event, a permission failure, a dependency failure, and the named safety boundary.
For each test return: input, expected state, prohibited side effect, and evidence to save.
Do not execute external actions.

Run the pack locally

The ZIP is a complete Node 22 starter with no third-party npm dependency. It includes an importable n8n webhook, Docker Compose, GitHub Actions validation and manual-run workflows, deterministic samples, and tests.

npm test
npm run validate
npm run sample
cp .env.example .env
docker compose up --build

Only set WORKFLOW_MODE=live, ANTHROPIC_API_KEY, and ANTHROPIC_MODEL after the dry-run output and tests make sense for your system. Keep real secrets in the environment, never in the n8n export.

Download the runnable pack

Start with the fictional dry-run. It validates the input and returns a reviewable draft without changing code, production data, customer accounts, or an external service.

Before enabling a real action

Replace every fictional fixture, assign the approval owner, define the duplicate key, set a timeout and retry rule, and save the original evidence. Then test one failure on purpose. If the workflow cannot stop visibly and replay safely, it is not ready to act.