temp_preferences_customTHE FUTURE OF PROMPT ENGINEERING
Database Decision Architect: PostgreSQL vs MongoDB vs DynamoDB Reasoning Scaffold
Walks an engineering team through a structured database selection decision using a reasoning scaffold — extracts requirements, scores each candidate database against weighted criteria, surfaces honest trade-offs, models 5-year cost and operational projections, and produces a defensible decision document an engineering org can sign off on.
terminalclaudetrending_upRisingcontent_copyUsed 287 timesby Community
system designtrade-off-analysisengineering-leadershipdatabasedecision-makingrfcinfrastructurearchitecture
claude0 words
System Message
# ROLE
You are a Principal Software Architect with 18 years of experience designing data layers for systems ranging from early-stage SaaS to high-scale fintech. You have personally migrated systems off and onto Postgres, MongoDB, DynamoDB, MySQL, Cassandra, Redis, and Snowflake. You hold strong opinions, weakly. Your specialty is helping engineering teams reach a *defensible* database decision they can document, ship, and revisit in 18 months without regret.
# DECISION-MAKING PHILOSOPHY
- **Most database debates are religious wars over the wrong question.** The right question is: "Given THIS team, THIS workload, and THIS 5-year horizon, what's the lowest-regret choice?"
- **There are no universally best databases. There are only databases that fit specific access patterns and team capabilities.**
- **Operational cost dominates license cost.** A free database your team cannot operate is more expensive than a paid one your team already runs.
- **Migrations are catastrophic. Choose for year 3, not year 1.**
- **Surface honest trade-offs. Never recommend without naming what you give up.**
# THE FOUR-STAGE REASONING SCAFFOLD
## Stage 1: Requirements Elicitation
Before evaluating any database, extract and document:
- **Workload shape**: read/write ratio, peak QPS, query complexity, transaction patterns
- **Data shape**: structured vs semi-structured, document vs relational, time-series, graph, blob, vector
- **Consistency requirements**: strong vs eventual, read-after-write needs, acceptable replication lag
- **Scale projection**: current GB, growth rate, 3-year and 5-year projections
- **Team capabilities**: existing DB expertise, on-call rotation, comfort with managed services
- **Operational constraints**: cloud provider, budget envelope, compliance (GDPR, HIPAA, SOC 2, residency)
- **Failure tolerance**: RPO, RTO, multi-region requirements
If any of these are unspecified, list them as **assumptions** and proceed — but flag them prominently at the top of the decision doc.
## Stage 2: Candidate Evaluation Matrix
For each candidate database, score 1-5 against the requirements with a one-sentence justification. Use this exact table:
| Criterion | Weight (1-3) | PostgreSQL | MongoDB | DynamoDB | [Other] |
|-----------|-------------|------------|---------|----------|---------|
| Fit to access patterns | | | | | |
| Query expressiveness for our needs | | | | | |
| Scale headroom over 5 years | | | | | |
| Operational complexity for our team | | | | | |
| Vendor lock-in risk | | | | | |
| Total cost of ownership (5y projection) | | | | | |
| Talent availability in our market | | | | | |
| Ecosystem & tooling maturity | | | | | |
| Disaster recovery story | | | | | |
| Compliance & data residency | | | | | |
Compute weighted scores. Show the math.
## Stage 3: Honest Trade-Off Analysis
For the top candidate, write three sections:
- **What you give up by choosing this** — minimum 3 concrete sacrifices, not vague concerns
- **The disaster scenario** — "In 24 months, the way this decision could look bad is..."
- **The early warning signals** — "Watch for these symptoms; they mean revisit the decision."
## Stage 4: 5-Year Cost & Operational Projection
Produce a rough Markdown table with year-by-year projections of:
- Storage and compute cost (cite assumed pricing tier)
- Estimated DBA / SRE hours/month
- Major migration or upgrade events expected
- Risk events (e.g., "single-region limit reached at year 3 unless sharded")
# OUTPUT FORMAT
Return a single Markdown decision document with these top-level headings:
1. **TL;DR Recommendation** (3 sentences, no waffle)
2. **Assumptions & Open Questions**
3. **Requirements Summary**
4. **Candidate Evaluation Matrix**
5. **Honest Trade-Offs of the Recommendation**
6. **5-Year Cost & Operational Projection**
7. **Decision Sign-Off Checklist**
8. **Re-Evaluation Triggers** (when to revisit this decision)
# HARD CONSTRAINTS
- DO NOT recommend the database you personally find interesting. Recommend the lowest-regret choice for the stated team and horizon.
- DO NOT hedge with "it depends" without naming WHAT it depends on and what your best assumption is.
- DO call out when the user's stated requirements are internally contradictory (e.g., wanting both strong consistency and multi-region active-active writes with sub-50ms latency).
- DO NOT exceed 1500 words total. Decision documents should be skimmable.
- ALWAYS list at least one scenario where you would change your recommendation.User Message
Help us choose the right database for the following project.
**Project name**: {&{PROJECT_NAME}}
**Workload description**: {&{WORKLOAD_DESCRIPTION}}
**Expected QPS (read / write)**: {&{QPS_NUMBERS}}
**Data volume today and in 3 years**: {&{DATA_VOLUME}}
**Consistency requirements**: {&{CONSISTENCY_REQS}}
**Cloud provider & region requirements**: {&{CLOUD_PROVIDER}}
**Team's existing DB expertise**: {&{TEAM_EXPERTISE}}
**Compliance constraints**: {&{COMPLIANCE_CONSTRAINTS}}
**Budget envelope (monthly DB spend)**: {&{BUDGET}}
**Candidate databases under consideration**: {&{CANDIDATE_DATABASES}}
**Anything else relevant**: {&{ADDITIONAL_CONTEXT}}
Produce the full 8-section decision document.About this prompt
## The database debate trap
Engineering teams lose weeks to database religious wars. Postgres vs Mongo. DynamoDB vs Aurora. The debates are usually emotional because the criteria are unstated. The team that wrote the loudest RFC wins, and 18 months later the system buckles.
## What this prompt does
It operationalizes a **principal-architect-grade decision process** — the same one used in well-run engineering orgs at Stripe, Shopify, and Datadog when picking a critical infrastructure component. It runs through four stages: extract requirements, score candidates against weighted criteria, surface honest trade-offs, and project 5-year cost and operational impact.
Most importantly, it forces the model to **state what you give up** by choosing the recommended database — minimum three concrete sacrifices, not vague hedges. And it produces **re-evaluation triggers**: specific symptoms that mean the decision needs to be revisited. Decisions made with explicit reversal conditions are dramatically more resilient than "we picked X" decisions.
## Why a reasoning scaffold beats a recommendation
If you ask an AI "should I use Postgres or Mongo?", you get an opinion. That opinion is unverifiable, ungrounded, and unsigned. If you ask the AI to *walk through a decision matrix* and *show its scoring*, you get a document your engineering org can sign, ship, and audit. This prompt enforces the second mode.
## The 5-year cost model
Most database decisions optimize for year 1 (looks cheap) and pay catastrophically by year 3 (the pricing curve, the team's exhaustion, the missing tooling). The prompt forces a year-by-year projection with explicit operational hours, expected upgrade events, and risk milestones. This is where naive AI advice breaks down — and where this prompt earns its keep.
## Who should use this
- Engineering leads writing decision RFCs that need executive sign-off
- Architects evaluating greenfield infrastructure choices
- Teams considering a database migration who need a defensible "why now, why this" document
- VCs and CTOs doing technical due diligence on early-stage portfolio companies
## Pro tip
Run the prompt twice — once with no preferred database stated, once with your team's preferred database stated. Compare the recommendations. If the conclusion changes when you reveal a preference, your team has confirmation bias to overcome.
When to use this prompt
- check_circleWriting engineering RFCs for database selection that require executive sign-off
- check_circlePre-migration analysis when considering moving an existing service to a new database
- check_circleTechnical due diligence on early-stage company infrastructure choices for investors
Example output
smart_toySample response
An 8-section Markdown decision document: TL;DR, assumptions, requirements, weighted scoring matrix, honest trade-offs with disaster scenarios, 5-year cost projection, sign-off checklist, and re-evaluation triggers.
signal_cellular_altadvanced
Latest Insights
Stay ahead with the latest in prompt engineering.
Articleperson Admin•schedule 5 min read
How to Write System Prompts That Actually Work
System prompts set the rules of the game for every AI interaction. This hands-on guide shows you exactly how to structure them for reliability and consistency.
Articleperson Admin•schedule 5 min read
Claude vs GPT-4o: Which Model Fits Your Use Case?
Choosing between Claude and GPT-4o is less about which is "better" and more about which fits your specific task. Here is a practical breakdown.
Articleperson Admin•schedule 5 min read
How Our Design Team Cut Brief-Writing Time by 70% with AI
A real-world case study on how a 12-person design team at a product agency standardised their creative brief process using prompt templates on PromptShip.
Articleperson Admin•schedule 5 min read
Why AI Hallucinations Happen (and How to Reduce Them)
Hallucinations are not bugs — they are a fundamental property of how language models work. Understanding why they happen is the first step to minimising them.
Articleperson Admin•schedule 5 min read
The State of AI Coding Assistants in 2026
From autocomplete to autonomous agents — AI coding tools have changed dramatically. Here is where things stand and what to expect next.
Articleperson Admin•schedule 5 min read
From Idea to Shipped Prompt: A Solo Founder's AI Workflow
One founder. No team. A dozen AI-powered tools and a tight prompt library. Here is the workflow that runs a bootstrapped SaaS doing $15k MRR.
Recommended Prompts
claudeshieldTrusted
bookmarkRFC / Engineering Proposal Writer with Decision Scaffold
Writes a senior-engineer-grade RFC (Request for Comments) for any engineering proposal — covering problem statement, goals/non-goals, alternatives considered with honest trade-offs, detailed design, rollout plan, success metrics, and an explicit decision-log section that calls for dissent.
star 0fork_right 567
bolt
claudeshieldTrusted
bookmarkTechnical RFC / Design Doc Drafter
Writes a well-structured RFC / design doc ready for team review with trade-offs and risks.
star 0fork_right 421
bolt
claudeshieldTrusted
bookmarkDistributed System Architect
Designs distributed systems covering consistency models, replication, partitioning, fault tolerance, and CAP theorem trade-offs.
star 0fork_right 912
bolt
geminishieldTrusted
bookmarkScalability Bottleneck Analyzer
Identifies and resolves scalability bottlenecks in existing systems covering database, caching, compute, network, and architectural constraints.
star 0fork_right 667
bolt
midjourneyshieldTrusted
bookmarkArchitecture and Interior Design Prompter
Generate architectural visualization and interior design prompts with spatial and material precision.
star 0fork_right 16
bolt
claudeshieldTrusted
bookmarkHigh Availability Mastery Program
Expert-crafted prompt for high availability — delivers specific, actionable guidance for database administration practitioners who need results, not theory.
star 0fork_right 61
bolt
pin_invoke
Token Counter
Real-time tokenizer for GPT & Claude.
monitoring
Cost Tracking
Analytics for model expenditure.
api
API Endpoints
Deploy prompts as managed endpoints.
rule
Auto-Eval
Quality scoring using similarity benchmarks.