Overview

You're evaluating a new database technology. Should you use PostgreSQL, MongoDB, Cassandra, DynamoDB, or something else? You read white papers. You ask colleagues. You look at Hacker News. Hacker News says use Rust. Twitter says use Go. Your CTO says use what we already know. You're now more confused than when you started.

Everyone has an opinion. No one has your constraints. No one understands your scale, your budget, your operational maturity, your specific performance requirements.

AI can help with this. Not by telling you the answer, but by helping you think through your specific constraints and what actually matters for your use case. It can stress-test your assumptions and show you reference implementations of how others solved similar problems.

Why Technology Decisions Are Hard

There's no such thing as a universally good technology. Every technology is a bundle of tradeoffs:

• PostgreSQL is consistent and mature but not horizontally scalable at the extreme. Operational burden is low.
  - MongoDB is flexible and scalable but can be loose with consistency. Operational burden is medium.
  - Cassandra is infinitely scalable but operationally complex and hard to reason about. Operational burden is very high.
  - DynamoDB is managed and scalable but expensive and inflexible. You're locked into AWS.

The "right" choice depends on multiple dimensions: What's your current scale and projected scale? How much operational complexity can you realistically handle? How much money do you have? How important is consistency vs. availability? How important is flexibility vs. stability? How important is time-to-market?

Without knowing your constraints, everyone's advice is wrong. The person saying "use Cassandra" might be thinking about Netflix-scale problems. You might be 100x smaller.

The Real Cost of Bad Decisions

Picking the wrong technology costs money. Not just the license cost. The cost of migrating away later. The cost of developers struggling with the technology. The cost of operational incidents. The cost of slower feature velocity.

Picking PostgreSQL when you need Cassandra means six months of struggling with scalability, then a painful migration. Picking Cassandra when you need PostgreSQL means years of operational complexity you don't need.

The Common Mistake: Teams pick technologies based on what's popular (Hacker News), what the senior engineer used at their last company (resume-driven development), or what someone on the internet said (survivorship bias). Not based on their actual constraints. This leads to mismatches that cause pain for years.

How AI Changes Technology Evaluation

Constraint Capture

Start by defining your constraints with AI's help. Ask Claude: "We're building a real-time analytics platform. Current scale: 100k users. Target scale: 10M users in 3 years. Budget: $50k/month. Team size: 4 engineers (2 senior, 2 junior). Latency requirement: p99
- "You said eventual consistency is fine. But you have financial transactions. Are you okay with double-counting revenue for a few seconds?"
- "You said p99

This forces you to be precise about what you actually need, not what you think sounds good.

Example Constraint Definition

Bad: "We need a scalable database." Good: "We need a database that handles 100k concurrent users, with p99 latency
- Performance: Latency at your scale, throughput, scalability trajectory
- Consistency: ACID guarantees vs. eventual consistency vs. configurable
- Operational burden: Monitoring, alerting, failover, capacity planning
- Developer productivity: Query language, library support, debugging tools
- Cost: License + hardware + operations at your scale
- Community: Stack Overflow questions, GitHub activity, hiring pool
- Maturity: How battle-tested? Companies running it at scale? Known gotchas?
- Interoperability: Works with your existing stack? APIs clean? Integrations available?

AI can score each technology across these dimensions for you, weighted by your priorities. Not objectively (all scoring is subjective), but consistently and thoroughly.

Example Scorecard

PostgreSQL: Performance 7/10 (good at your scale, not infinite), Consistency 10/10, Operations 9/10, Dev Productivity 9/10, Cost 8/10, Community 10/10, Maturity 10/10, Interop 9/10. Total: 72/80.

Cassandra: Performance 10/10 (infinite scale), Consistency 5/10 (eventual only), Operations 4/10 (very hard), Dev Productivity 6/10 (awkward queries), Cost 7/10, Community 6/10, Maturity 9/10, Interop 5/10. Total: 52/80.

For your constraints, PostgreSQL wins. But the scorecard shows you where Cassandra would be better (if you scaled 100x and had a dedicated ops team).

Stress Test Your Assumptions

Before you decide, have AI challenge your assumptions. "You said you can tolerate eventual consistency. But what if a customer updates their payment method and immediately tries to use it? That's a consistency problem. How will you handle that?"

You might answer: "Good point. We'll use strong consistency for payment data, eventual for everything else." Or: "That's fine, we'll show a 'processing' message and check again in 10 seconds." Either way, you've thought it through.

Reference Implementations

AI can show you reference implementations: "Here's how Airbnb solved this with PostgreSQL. Here's how Uber solved it with Cassandra. Here's how Stripe solved it with PostgreSQL + Redis." You see how each choice plays out in reality at different scales.

Migration Path Analysis

You won't get your technology decision right forever. You'll need to evolve. Ask AI: "If we start with PostgreSQL and later need to migrate to Cassandra at 100M scale, what's the migration path? How hard is it? What do we need to design now to make that future migration easier?"

This changes your initial decision. Instead of optimizing for today, you optimize for the future. You pick PostgreSQL (simpler), but design your schema and APIs so migrating to Cassandra later is possible (log-structured, no joins, immutable data where possible).

Case Study: AI-Assisted Database Selection

A B2B analytics company was evaluating databases for a new product: real-time analytics on customer transaction data. Their candidates: PostgreSQL (comfortable choice), Elasticsearch (search-first), TimescaleDB (time-series specialist). They used AI to evaluate across multiple dimensions.

Manual evaluation would have taken 20 hours (research, benchmark, trial deploys). AI-assisted took 4 hours: 1) Defined constraints using AI prompts (scale: 1M events/second, p99 latency < 2 seconds, retention 90 days, cost < $50k/month). 2) AI created detailed scorecard across performance, operational burden, dev experience, cost, future scalability. 3) AI stress-tested each choice (what goes wrong? how does each handle data model changes? migration costs?). 4) AI provided reference implementations (how does Elastic handle their scale? How does TimescaleDB scale?)

Outcome: They chose TimescaleDB (PostgreSQL + time-series optimizations) based on superior performance at their scale + easier migration path than Elasticsearch. They deployed a POC in 2 weeks, validated performance, and rolled out. 6 months later: handling 500k events/second (well within their forecasts), p99 latency 1.4 seconds, operational costs $18k/month. The decision was right because they'd thought through the constraints thoroughly with AI.

Adversarial Case Study: The Elasticsearch Mistake

A fintech company was building a transaction search product. They evaluated three technologies: Elasticsearch (search-first database), PostgreSQL with indexing, and a custom solution. At the time (2020), Elasticsearch was trendy. GitHub stars: 60K. Twitter was full of Elasticsearch success stories. They chose Elasticsearch based on "it's what search companies use."

They built their product on Elasticsearch. It worked great at 100K transactions. At 1M, performance was still good. At 50M transactions, latency started increasing. At 100M, things broke. Elasticsearch's memory usage exploded. Cluster became unstable. They had production incidents: 30-minute outages, data inconsistencies. The fix required a complete architectural rewrite.

Root cause (discovered in post-mortem): Elasticsearch is optimized for full-text search, not dense numeric data. The fintech's transaction dataset was 90% structured data (dates, amounts, account IDs), 10% searchable text. For their use case, PostgreSQL with proper indexing would have been cheaper, simpler, and faster at their scale. PostgreSQL would have cost $20K/month at scale. Elasticsearch cost $80K/month and required a dedicated ops team.

They spent 6 months rebuilding on PostgreSQL. Lost 3 months of feature development. Burned credibility with customers (two production incidents). Cost of mistake: 6 months engineer time ($500K), customer churn ($200K), operational overhead ($300K) = ~$1M.

What went wrong: They didn't do constraint-based evaluation. They picked based on popularity, not on fit. If they'd used AI-assisted evaluation, they would have documented their constraints upfront: "Dense structured data. 100M+ records at 18 months. p99 latency < 2 seconds. Need consistent performance as scale increases." With those constraints, PostgreSQL would have scored higher because it handles structured data better and scales more predictably.

Lesson: Evaluation frameworks matter. Trendy tech fails when it doesn't match your constraints. Use AI to force constraint-driven evaluation, not hype-driven.

Implementing AI-Assisted Tech Evaluation in Your Organization

Create an Evaluation Framework with Quantitative Thresholds

Document your decision framework with specific, measurable criteria:

• Mandatory constraints (must pass or you don't evaluate further):
  - Cost:

Write this down. Share it with your team. Use it as the basis for every evaluation. This prevents arguing about the same things repeatedly.

Develop Technology Standards with Measurable Exceptions

You can't evaluate everything from scratch every time. Establish standards with quantitative exceptions: "For databases, we prefer PostgreSQL unless: (1) You need to handle > 50M rows with
- Define the problem you're solving (what does this technology need to do?)
- List your constraints (scale, budget, operations, team)
- Identify 3-5 candidate technologies (at least one conservative, one aggressive)
- Score each on the dimensions that matter to you
- Stress-test your assumptions with AI (what could go wrong?)
- Make a decision with documented reasoning (why this one?)
- Plan how you'll validate the decision (PoC? Limited rollout? Monitoring?)
- Plan the rollback (what if we're wrong?)

Use Claude or your AI tool to help with each step. Especially step 5 (stress testing) is where AI adds value.

Learn from Past Decisions

Every technology decision you make teaches you something. Keep a technology decision log:

• Date and decision: "2025-06-15: Chose PostgreSQL for analytics platform"
  - Constraints: "100k to 10M scale, eventual consistency acceptable, $50k/month budget"
  - Candidates considered: "PostgreSQL, MongoDB, Cassandra"
  - Reasoning: "PostgreSQL scored highest on our criteria, easiest to migrate from"
  - Outcome (6 months later): "Working well. p99 latency is 120ms. Ops burden is low. Scaling well to 2M users."
  - Lessons: "Good choice. Can stay with PostgreSQL for another 6-12 months."

Review this log every quarter. Ask: "Are our past decisions still good? Have constraints changed? Should we revisit anything?" Use AI to help you analyze what you learned.

What to Do Monday Morning

• Identify a pending technology decision on your roadmap (or if none, pick a past decision to retrospect on)
  - Write down your constraints and priorities (be specific: numbers, not vague goals)
  - List 3-5 candidate technologies (include at least one conservative choice and one aggressive choice)
  - Use Claude to create a scorecard for each technology across key dimensions
  - Have Claude stress-test your assumptions (what could go wrong with each choice?)
  - Compare the AI's analysis to your gut instinct (do they match? if not, why?)
  - Make a decision with documented reasoning (what were the tradeoffs?)
  - Create a validation plan (how will you know if this was the right choice?)

FAQ

Q: Can AI replace an experienced architect for tech decisions?

A: No. AI is a tool, not a replacement. The architect's judgment on what tradeoffs matter is critical. AI helps them think through the options faster, more thoroughly, and more systematically. A bad architect with AI is still bad. A good architect with AI is better.

Q: What if the AI recommends something we disagree with?

A: Ask it why. Get the reasoning. Then you decide if the reasoning is sound. You might discover you missed something important (good). You might discover the AI's reasoning is flawed (also good. You learned that AI makes mistakes). Either way, you learn more than you would have guessing.

Q: Does this work for major decisions (e.g., moving from monolith to microservices)?

A: Yes, with more nuance. For big decisions, AI can help you stress-test your thinking, show you how companies did it, and highlight organizational challenges. But these decisions also require change management, which AI can inform but not replace.

Q: How do we avoid getting trapped by a bad decision?

A: By building reversibility into your decisions. When you evaluate a technology, also evaluate: how hard would it be to switch away? Design for switchability when possible. Keep major decisions reversible. This changes your evaluation: you might pick the medium option (easier to migrate from) over the best option (harder to migrate from).

Q: How long does a full technology evaluation take?

A: With AI assistance: 4-8 hours. First hour defining constraints, 2-3 hours with AI evaluating options and stress-testing, 1-2 hours documenting the decision and planning validation. Without AI: 2-4 weeks of reading white papers and talking to people.

Q: What if new constraints emerge after we've made a decision?**

A: This is common. New constraints invalidate old decisions. Keep your decision reversible (by design). When constraints change, re-evaluate quickly with AI instead of defaulting to your old choice. A company that can re-evaluate in 4 hours beats a company that's locked into a decision they made 6 months ago.

Key Insight

AI-assisted technology evaluation doesn't replace judgment. It enhances it. It forces you to be precise about constraints, consider more options systematically, and stress-test assumptions before you commit. That leads to better decisions faster. A decision made in a day with AI is usually better than a decision made in a month with committees.

On This Page

Watch the Lecture
Why Technology Decisions Are Hard
How AI Changes Technology Evaluation
Implementing AI-Assisted Evaluation
Monday Morning Action
FAQ

Chapter Details

Part ofChapter 3