dojo.md 0.1.0 → 0.2.1

package/courses/postgresql-query-optimization/scenarios/level-4/vendor-evaluation.yaml

@@ -0,0 +1,73 @@
+meta:
+  id: vendor-evaluation
+  level: 4
+  course: postgresql-query-optimization
+  type: output
+  description: "Evaluate PostgreSQL hosting vendors — compare RDS, Aurora, self-managed, Citus, and other options for enterprise workloads"
+  tags: [PostgreSQL, vendor-evaluation, RDS, Aurora, Citus, TCO, expert]
+
+state: {}
+
+trigger: |
+  Your company is evaluating PostgreSQL hosting options for a
+  platform migration. The CTO wants a comprehensive comparison
+  with TCO analysis over 3 years.
+
+  Current state: Self-managed PostgreSQL on bare metal
+  - 5 database clusters, 20 instances total
+  - 10TB total data
+  - 100K queries/second peak
+  - 3 DBAs managing the infrastructure
+  - Annual infrastructure cost: $800K
+  - Annual DBA salary cost: $600K
+  - Monthly operational incidents: 3 (average)
+
+  Vendors to evaluate:
+
+  1. AWS RDS for PostgreSQL:
+  - Managed service, automated backups, Multi-AZ
+  - db.r6g.4xlarge ($2.46/hr) × 20 instances
+
+  2. AWS Aurora PostgreSQL:
+  - Distributed storage, up to 15 read replicas
+  - db.r6g.4xlarge ($3.28/hr) × 10 instances (Aurora needs fewer)
+
+  3. Self-managed on AWS EC2:
+  - Full control, Patroni for HA
+  - r6g.4xlarge ($0.81/hr) × 20 instances + EBS storage
+
+  4. Citus Cloud (Azure):
+  - Distributed PostgreSQL, horizontal scaling
+  - Multi-tenant SaaS pattern support
+
+  5. Neon (serverless PostgreSQL):
+  - Scale to zero, branching, compute-storage separation
+  - Pay per compute-second
+
+  Evaluation criteria:
+  - Total Cost of Ownership (3-year)
+  - Performance (latency, throughput)
+  - Availability (SLA guarantees)
+  - Operational burden (DBA time saved)
+  - Migration complexity
+  - Lock-in risk
+  - Compliance (SOC 2, PCI DSS, HIPAA)
+
+  Task: Write the vendor evaluation report. Include: the TCO
+  comparison (3-year costs including hidden costs), the performance
+  benchmark plan, the migration risk assessment per vendor, the
+  recommendation with justification, and the executive summary.
+
+assertions:
+  - type: llm_judge
+    criteria: "TCO analysis includes hidden costs — considers not just instance pricing but also storage, IOPS, data transfer, backup storage, DBA time reduction (or increase), migration cost, training, and the cost of vendor lock-in. 3-year totals are calculated for each option"
+    weight: 0.35
+    description: "Comprehensive TCO analysis"
+  - type: llm_judge
+    criteria: "Evaluation is balanced — each vendor has pros and cons documented, the recommendation is justified by the company's specific needs (not just cheapest), and lock-in risk is honestly assessed (Aurora's proprietary storage layer, Citus's distributed query limitations)"
+    weight: 0.35
+    description: "Balanced vendor evaluation"
+  - type: llm_judge
+    criteria: "Migration risk and operational impact are assessed — estimates migration timeline per vendor, identifies features that don't transfer (extensions, custom configs), and calculates DBA staffing changes (managed services may reduce 3 DBAs to 1, but requires cloud expertise)"
+    weight: 0.30
+    description: "Migration and operational assessment"

package/courses/postgresql-query-optimization/scenarios/level-5/comprehensive-database-system.yaml

@@ -0,0 +1,70 @@
+meta:
+  id: comprehensive-database-system
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Design a comprehensive database platform — architect the complete PostgreSQL infrastructure for a 10,000-engineer organization from provisioning to observability"
+  tags: [PostgreSQL, platform, infrastructure, self-service, observability, master]
+
+state: {}
+
+trigger: |
+  You're the VP of Database Platform at a Fortune 500 company with
+  10,000 engineers. The CEO has mandated a "database as a platform"
+  initiative — engineers should be able to provision, use, and manage
+  databases without filing tickets or waiting for DBAs.
+
+  Current state (the problem):
+  - 500 PostgreSQL databases across 100 teams
+  - Average time to provision a new database: 3 weeks (ticket-based)
+  - 20 DBAs handling all requests (bottleneck)
+  - No self-service: every schema change requires DBA approval
+  - Each team configures databases differently
+  - Incident response depends on which DBA is on-call (inconsistent)
+  - No cost attribution — database costs appear as one lump sum
+
+  Target state (the vision):
+  - Self-service database provisioning in <5 minutes
+  - Automated schema change review and deployment
+  - Unified observability across all 500 databases
+  - Cost attribution to individual teams and services
+  - Automated incident detection and remediation
+  - DBA team transitions from ticket-taking to platform engineering
+  - Compliance and security automatically enforced
+
+  Platform components to design:
+  1. Provisioning layer: Self-service database creation with guardrails
+  2. Schema management: GitOps-based schema changes with CI/CD
+  3. Query governance: Automated performance review before deployment
+  4. Observability: Unified monitoring, alerting, and dashboards
+  5. Cost management: Per-team cost tracking and budget alerts
+  6. Security: Automated encryption, access control, audit logging
+  7. Disaster recovery: Automated backup, tested recovery, failover
+  8. Developer experience: CLI tools, documentation, onboarding
+
+  Constraints:
+  - Must support both on-premises and cloud (hybrid)
+  - Must integrate with existing CI/CD (Jenkins, GitHub Actions)
+  - Must meet SOC 2, PCI DSS, HIPAA compliance
+  - Budget: $5M/year for the platform team (20 engineers)
+  - Migration timeline: 18 months to onboard all 500 databases
+
+  Task: Design the database platform. Write: the platform architecture
+  (all 8 components), the self-service provisioning design, the
+  governance model (what's automated vs what needs human approval), the
+  migration strategy (onboarding 500 existing databases), and the
+  success metrics for the platform.
+
+assertions:
+  - type: llm_judge
+    criteria: "Platform architecture covers all 8 components — provisioning (Kubernetes operator or Terraform modules), schema management (GitOps with migration tools), query governance (CI/CD integration), observability (centralized metrics, logs, traces), cost management (tagging and attribution), security (automated encryption and RBAC), DR (automated backup testing), and developer experience (CLI, docs, golden path templates)"
+    weight: 0.35
+    description: "Complete platform architecture"
+  - type: llm_judge
+    criteria: "Self-service design balances autonomy with governance — engineers can provision databases instantly within guardrails (size limits, approved configurations, automatic security settings), schema changes go through automated review (blocking dangerous operations, approving safe ones), and the governance model defines clear boundaries (what's self-service vs what needs platform team approval)"
+    weight: 0.35
+    description: "Balanced self-service governance"
+  - type: llm_judge
+    criteria: "Migration strategy and success metrics are realistic — onboards 500 databases in phases (start with willing teams, then high-value, then mandatory), defines success metrics (provisioning time, incident MTTR, DBA ticket volume, team satisfaction, cost per database), and the 20-engineer platform team structure is defined with clear roles"
+    weight: 0.30
+    description: "Realistic migration and metrics"

package/courses/postgresql-query-optimization/scenarios/level-5/database-ai-future.yaml

@@ -0,0 +1,81 @@
+meta:
+  id: database-ai-future
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Explore the future of AI-powered database optimization — evaluate autonomous tuning, AI query optimization, vector search integration, and the evolving role of DBAs"
+  tags: [PostgreSQL, AI, machine-learning, autonomous-tuning, vector-search, future, master]
+
+state: {}
+
+trigger: |
+  Your CTO asks you to evaluate how AI will transform PostgreSQL
+  operations over the next 3-5 years and recommend which AI-powered
+  database technologies to invest in now.
+
+  Current AI-database landscape:
+
+  1. Autonomous tuning:
+     - OtterTune / DBtune: ML-based parameter tuning
+     - They claim 2-5x performance improvement by optimizing postgresql.conf
+     - But: tuning 300+ parameters requires understanding workload patterns
+     - Question: Is this better than a senior DBA tuning manually?
+
+  2. AI query optimization:
+     - Learned query optimizers (Bao, Neo, Balsa)
+     - They replace PostgreSQL's cost-based optimizer with ML models
+     - Claim: 50% improvement on complex queries vs traditional optimizer
+     - But: require training data, cold start problem, unpredictable behavior
+     - Question: Should we replace PostgreSQL's battle-tested optimizer?
+
+  3. AI-powered indexing:
+     - Index advisor tools (Dexter, HypoPG + ML)
+     - Automatically recommend indexes based on workload analysis
+     - Question: How good are they vs experienced DBA recommendations?
+
+  4. Vector search in PostgreSQL:
+     - pgvector: native vector similarity search
+     - pgvectorscale: improved indexing for high-dimensional vectors
+     - Use case: Semantic search, RAG, recommendation systems
+     - Question: Should we use PostgreSQL for vectors or a dedicated
+       vector DB (Pinecone, Weaviate, Qdrant)?
+
+  5. Natural language to SQL:
+     - Text-to-SQL models (GPT-4, Claude, specialized models)
+     - Enable non-technical users to query the database
+     - But: security risks, performance risks (generated queries may be slow)
+     - Question: How to safely deploy text-to-SQL in production?
+
+  6. Predictive operations:
+     - ML models that predict: disk full, replication lag spike, query
+       degradation, connection pool exhaustion
+     - Proactive alerts before incidents happen
+     - Question: What data do we need to collect now to enable this?
+
+  Your evaluation criteria:
+  - Production readiness (can we use it today?)
+  - ROI (does the benefit justify the complexity?)
+  - Risk (what happens when the AI is wrong?)
+  - PostgreSQL compatibility (native extension vs external tool?)
+  - Team skill requirements (do we need ML engineers?)
+
+  Task: Write the technology evaluation. Include: the assessment of
+  each AI-database technology (production readiness, ROI, risk), the
+  recommended adoption roadmap (what to adopt now, what to watch, what
+  to skip), the pgvector strategy (PostgreSQL vs dedicated vector DB),
+  the text-to-SQL safety framework, and the prediction of how the DBA
+  role evolves with AI.
+
+assertions:
+  - type: llm_judge
+    criteria: "Each technology is honestly assessed — evaluates production readiness realistically (autonomous tuning: semi-ready, learned optimizers: research stage, index advisors: ready for recommendations, pgvector: production-ready for moderate scale, text-to-SQL: risky without guardrails, predictive ops: early but promising). Avoids both hype and dismissiveness"
+    weight: 0.35
+    description: "Honest technology assessment"
+  - type: llm_judge
+    criteria: "Adoption roadmap is practical — separates 'adopt now' (pgvector, index advisors, predictive monitoring), 'evaluate' (autonomous tuning, text-to-SQL with guardrails), and 'watch' (learned optimizers). Each recommendation includes implementation complexity, team skill requirements, and expected ROI timeline"
+    weight: 0.35
+    description: "Practical adoption roadmap"
+  - type: llm_judge
+    criteria: "DBA role evolution and safety frameworks are addressed — discusses how AI augments rather than replaces DBAs (shift from manual tuning to AI supervision, from reactive to predictive), and the text-to-SQL safety framework includes query validation, cost limits, read-only access, result set limits, and audit logging"
+    weight: 0.30
+    description: "DBA evolution and safety"

package/courses/postgresql-query-optimization/scenarios/level-5/database-behavioral-science.yaml

@@ -0,0 +1,63 @@
+meta:
+  id: database-behavioral-science
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Apply behavioral science to database operations — design systems that nudge engineers toward good query practices and prevent performance anti-patterns"
+  tags: [PostgreSQL, behavioral-science, nudge-theory, developer-experience, culture, master]
+
+state: {}
+
+trigger: |
+  Your organization has 400 engineers writing queries against PostgreSQL.
+  Despite documentation, training, and code reviews, the same performance
+  anti-patterns keep appearing: SELECT *, missing indexes on foreign keys,
+  N+1 queries, unfiltered aggregations on large tables, and long-running
+  transactions holding locks.
+
+  You've tried traditional approaches:
+  - Wiki documentation: 15% of engineers read it
+  - Quarterly training sessions: Attendance drops 50% after first session
+  - Code review checklist: Reviewers skip database items under time pressure
+  - Slack channel for DB questions: Same 5 people answer, 10 people ask
+
+  Anti-pattern frequency (last quarter):
+  - SELECT * on tables with 50+ columns: 120 new instances
+  - Missing WHERE clause on UPDATE/DELETE: 8 incidents (3 in production)
+  - N+1 queries in new endpoints: 45 instances
+  - Queries without LIMIT on unbounded result sets: 67 instances
+  - ALTER TABLE without CONCURRENTLY on large tables: 12 instances
+  - Long transactions (>5 min) blocking autovacuum: 30 incidents
+
+  Behavioral science concepts to apply:
+  1. Choice architecture: Make the right thing the default
+  2. Nudge theory: Gentle prompts at the right moment
+  3. Feedback loops: Immediate visibility of consequences
+  4. Social proof: Show what good teams are doing
+  5. Friction: Make bad patterns slightly harder, good patterns easier
+  6. Gamification: Make query optimization engaging
+
+  The VP of Engineering says: "We can't review every query manually.
+  We need a system where engineers naturally write good queries without
+  needing a DBA to catch every mistake."
+
+  Task: Design the behavioral system for database excellence. Write:
+  the choice architecture (how to make good defaults), the automated
+  nudge system (when and how to prompt engineers), the feedback loop
+  design (showing query impact in real-time), the social proof
+  mechanisms (leaderboards, team comparisons), and the organizational
+  change management plan.
+
+assertions:
+  - type: llm_judge
+    criteria: "Choice architecture makes good practices the default — ORM configuration defaults to safe patterns (SELECT with explicit columns, query timeouts, connection limits), migration tools default to CONCURRENTLY for index creation, CI/CD pipeline includes automatic EXPLAIN analysis that flags anti-patterns before merge, and database client libraries include built-in guardrails"
+    weight: 0.35
+    description: "Effective choice architecture"
+  - type: llm_judge
+    criteria: "Nudge system intervenes at the right moment — IDE plugins that warn about SELECT * as you type, PR bot that comments with query performance estimates, pre-deploy checks that show estimated query cost, and post-deploy dashboards that attribute latency changes to specific deployments. Nudges are informative, not blocking (most of the time)"
+    weight: 0.35
+    description: "Well-timed nudge system"
+  - type: llm_judge
+    criteria: "Feedback loops and social proof create sustainable improvement — real-time query performance dashboard per team, weekly automated reports comparing team query performance, gamification elements (query optimization challenges, leaderboards), and the change management plan addresses resistance (making it fun, not punitive) with measurable success metrics"
+    weight: 0.30
+    description: "Sustainable feedback and social proof"

package/courses/postgresql-query-optimization/scenarios/level-5/database-board-strategy.yaml

@@ -0,0 +1,77 @@
+meta:
+  id: database-board-strategy
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Present database strategy to the board — frame PostgreSQL infrastructure as a strategic asset, quantify technical debt, and secure multi-year investment"
+  tags: [PostgreSQL, board-strategy, investment, technical-debt, governance, master]
+
+state: {}
+
+trigger: |
+  You're the CTO presenting the database infrastructure strategy to
+  the Board of Directors at the quarterly meeting. The board includes
+  3 technical members and 4 non-technical members. You need to secure
+  approval for a $5M, 3-year database modernization program.
+
+  Company context:
+  - $200M ARR SaaS platform, 5,000 enterprise customers
+  - IPO planned in 18 months
+  - Due diligence will examine infrastructure scalability
+  - Current database: 30 PostgreSQL clusters, 50TB total
+  - 8 DBAs, $3.5M/year database infrastructure cost
+  - 3 major outages last year (total 14 hours downtime)
+  - Customer-facing latency SLA: 99.9% of requests <200ms
+  - Current achievement: 99.2% (SLA breach, contractual penalties possible)
+
+  The $5M modernization program includes:
+  Year 1 ($2M):
+  - Consolidate 30 clusters to 15 (eliminate redundancy)
+  - Implement automated query review pipeline
+  - Deploy comprehensive monitoring (pg_stat_statements, pgwatch2)
+  - Partition all tables >100M rows
+  - Upgrade all clusters to PG 16
+
+  Year 2 ($1.8M):
+  - Migrate to managed service (Aurora) for 10 clusters
+  - Implement multi-region disaster recovery
+  - Reduce DBA team from 8 to 5 (3 transition to platform engineering)
+  - Achieve 99.95% latency SLA compliance
+
+  Year 3 ($1.2M):
+  - Achieve 99.99% availability
+  - Implement auto-scaling for variable workloads
+  - Reduce infrastructure cost by 30% through optimization
+  - Full self-service database provisioning for engineering teams
+
+  Expected outcomes:
+  - Infrastructure cost: $3.5M/year → $2.5M/year by Year 3
+  - Downtime: 14 hours/year → <1 hour/year
+  - SLA compliance: 99.2% → 99.99%
+  - Engineering velocity: 40% faster feature delivery (less DB bottleneck)
+
+  Board member concerns:
+  - "Why not just move everything to the cloud and let AWS handle it?"
+  - "Can't we just hire more DBAs instead of spending $5M?"
+  - "What if we delay this until after the IPO?"
+  - "How does this compare to what our competitors are doing?"
+
+  Task: Write the board presentation narrative. Include: the strategic
+  framing (database as competitive advantage), the investment case with
+  ROI, the risk of inaction (IPO due diligence, SLA penalties, customer
+  churn), the phased execution plan, and prepared responses to the 4
+  board concerns.
+
+assertions:
+  - type: llm_judge
+    criteria: "Strategic framing resonates with board audience — presents the database as a business asset (not just infrastructure), connects reliability to customer retention and revenue, frames the investment in context of IPO readiness, and uses business language (not technical jargon) for non-technical board members"
+    weight: 0.35
+    description: "Board-appropriate strategic framing"
+  - type: llm_judge
+    criteria: "Investment case is compelling — ROI is clearly calculated ($5M investment vs quantified returns: $1M/year cost reduction, avoided SLA penalties, reduced outage costs, IPO readiness), risk of inaction is quantified (SLA penalty exposure, due diligence failure risk, customer churn from outages), and the phased approach reduces execution risk"
+    weight: 0.35
+    description: "Compelling investment case"
+  - type: llm_judge
+    criteria: "Board concerns are addressed directly — explains why lift-and-shift to cloud isn't sufficient (still need optimization, higher cost without tuning), why more DBAs don't solve the structural problem, why delaying risks IPO timeline and increases cost, and provides competitive context. Responses are concise and business-focused"
+    weight: 0.30
+    description: "Board concerns addressed"

package/courses/postgresql-query-optimization/scenarios/level-5/database-consulting-engagement.yaml

@@ -0,0 +1,61 @@
+meta:
+  id: database-consulting-engagement
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Lead a database consulting engagement — assess a client's PostgreSQL infrastructure, identify optimization opportunities, and deliver a transformation roadmap"
+  tags: [PostgreSQL, consulting, assessment, transformation, roadmap, master]
+
+state: {}
+
+trigger: |
+  You're a PostgreSQL consulting lead hired by a Series C fintech
+  company ($500M valuation) that's experiencing database growing pains.
+  They've doubled their engineering team to 200 in the past year, and
+  their PostgreSQL infrastructure is struggling to keep up.
+
+  Client briefing:
+  - Company: PayStream (B2B payment processing)
+  - Revenue: $80M ARR, growing 100% YoY
+  - Transaction volume: 10M transactions/day, projected 50M in 12 months
+  - Database: 8 PostgreSQL clusters, 3TB total, mix of PG 13 and PG 15
+  - Team: 2 DBAs (both joined <6 months ago), 15 backend engineers
+  - Monthly infrastructure cost: $120K (growing 20%/quarter)
+
+  Assessment findings (your first week):
+  1. Performance: 40% of API endpoints exceed 500ms P99 latency
+  2. Schema: 15 tables over 1B rows with no partitioning
+  3. Indexes: 2,000 indexes total, estimated 40% unused (wasting 400GB)
+  4. Queries: Top 50 queries consume 80% of database CPU
+  5. Configuration: All 8 clusters use identical postgresql.conf despite
+     wildly different workloads (OLTP, reporting, event storage)
+  6. Monitoring: Basic CloudWatch only — no query-level visibility
+  7. No connection pooling on 5 of 8 clusters
+  8. Backups: Daily pg_dump (takes 6 hours), never tested restoration
+  9. Version: 3 clusters still on PG 13 (EOL approaching)
+  10. No query review process — any engineer can deploy any query
+
+  The CEO says: "We're spending more on database infrastructure every
+  quarter. Our engineers complain the database is slow. Our DBAs are
+  overwhelmed. We need a plan to fix this before our Series D."
+
+  Task: Write the consulting deliverable. Include: the executive
+  assessment (current state in business terms), the prioritized
+  optimization roadmap (quick wins, medium-term, long-term), the
+  staffing and organizational recommendations, the cost projection
+  (infrastructure costs with and without optimization), and the risk
+  register (what happens if they don't act).
+
+assertions:
+  - type: llm_judge
+    criteria: "Assessment translates technical findings into business impact — quantifies the cost of poor performance (revenue impact of 500ms latency, cost of unused indexes, risk of untested backups), prioritizes findings by business impact, and presents a clear current-state summary that a CEO can understand"
+    weight: 0.35
+    description: "Business-impact assessment"
+  - type: llm_judge
+    criteria: "Roadmap is prioritized and realistic — quick wins (drop unused indexes, deploy PgBouncer, tune top 50 queries) deliver measurable improvement in 2-4 weeks, medium-term (partition large tables, upgrade PG 13→16, implement monitoring) in 2-3 months, long-term (query review process, architecture evolution) in 6-12 months. Each phase has estimated cost savings"
+    weight: 0.35
+    description: "Prioritized optimization roadmap"
+  - type: llm_judge
+    criteria: "Staffing and cost projections are realistic — recommends DBA team growth or managed service adoption, projects infrastructure costs with optimization (reducing growth rate) vs without (linear extrapolation), and presents a compelling case for investment before Series D (database health as investor due diligence concern)"
+    weight: 0.30
+    description: "Staffing and cost projections"

package/courses/postgresql-query-optimization/scenarios/level-5/database-industry-benchmarks.yaml

@@ -0,0 +1,64 @@
+meta:
+  id: database-industry-benchmarks
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Design and interpret database benchmarks — create meaningful PostgreSQL benchmarks, avoid common pitfalls, and use benchmarks for capacity planning and vendor selection"
+  tags: [PostgreSQL, benchmarks, TPC, pgbench, performance-testing, capacity-planning, master]
+
+state: {}
+
+trigger: |
+  Your company needs to make a $2M infrastructure decision — whether to
+  migrate from self-managed PostgreSQL to Aurora PostgreSQL. The CTO
+  says "run some benchmarks and tell me which is faster." You know that
+  naive benchmarking leads to wrong conclusions, so you need to design
+  a rigorous benchmark that actually answers the right questions.
+
+  Context:
+  - Current: Self-managed PG 16 on r6g.4xlarge (16 vCPU, 128GB RAM)
+  - Candidate: Aurora PG 16 on db.r6g.4xlarge (same compute class)
+  - Workload: Mixed OLTP (70% reads, 30% writes), 50K TPS peak
+  - Data size: 500GB active dataset, 2TB total
+  - Critical queries: Point lookups, range scans, complex joins, bulk inserts
+
+  Common benchmarking mistakes you've seen teams make:
+  1. Using pgbench with default scale factor (fits entirely in RAM)
+  2. Benchmarking with empty tables (no realistic data distribution)
+  3. Running benchmarks for 5 minutes (not long enough for caches to warm)
+  4. Testing on a quiet system (no concurrent workload)
+  5. Ignoring storage performance (only testing CPU-bound queries)
+  6. Not testing failure scenarios (how does performance degrade under
+     replica failure, disk pressure, connection storms?)
+  7. Comparing list price vs actual cost (ignoring IOPS charges, data
+     transfer, backup costs)
+
+  Industry standard benchmarks:
+  - TPC-C: OLTP transactions (orders, payments, deliveries)
+  - TPC-H: Analytical queries (decision support)
+  - pgbench: PostgreSQL-specific, configurable
+  - sysbench: General-purpose database benchmark
+  - HammerDB: TPC-C/TPC-H implementation for PostgreSQL
+
+  Your VP asks: "Can you give me a number — queries per second on
+  Aurora vs self-managed — by Friday?"
+
+  Task: Design the benchmark plan. Write: the benchmark methodology
+  (what to test, how to test, how long), the workload design (realistic
+  representation of your actual workload), the metrics to collect and
+  how to interpret them, the pitfalls to avoid, and the decision
+  framework (how benchmark results translate into the migration decision).
+
+assertions:
+  - type: llm_judge
+    criteria: "Benchmark methodology is rigorous — tests realistic data volume (500GB+ to exceed RAM), runs long enough for steady state (hours, not minutes), includes warm-up phase, tests under concurrent load matching production patterns, and tests both normal operation and degraded modes (replica failure, high connection count)"
+    weight: 0.35
+    description: "Rigorous benchmark methodology"
+  - type: llm_judge
+    criteria: "Workload design represents real usage — captures the 70/30 read/write mix, includes representative query types (point lookups, range scans, complex joins, bulk inserts), uses realistic data distributions (not uniform), and tests at multiple concurrency levels (10, 50, 100, 500 connections) to find saturation points"
+    weight: 0.35
+    description: "Realistic workload design"
+  - type: llm_judge
+    criteria: "Decision framework goes beyond QPS — considers latency percentiles (P50/P95/P99), throughput under load, cost-per-transaction, operational overhead, failure behavior, and long-term cost trajectory. Acknowledges that benchmarks are one input to the decision alongside operational, compliance, and strategic factors"
+    weight: 0.30
+    description: "Holistic decision framework"

package/courses/postgresql-query-optimization/scenarios/level-5/database-ma-integration.yaml

@@ -0,0 +1,71 @@
+meta:
+  id: database-ma-integration
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Plan database integration after M&A — merge two companies' PostgreSQL infrastructures while maintaining service continuity"
+  tags: [PostgreSQL, M&A, integration, data-migration, schema-merge, master]
+
+state: {}
+
+trigger: |
+  Your company (AcmePay, $200M ARR) just acquired a competitor
+  (QuickBill, $50M ARR). Both run on PostgreSQL. The board mandates
+  full technology integration within 12 months. You're leading the
+  database integration.
+
+  AcmePay (acquirer):
+  - PostgreSQL 16 on Aurora, 20 clusters, 30TB
+  - Well-documented schema, strong naming conventions
+  - 500 tables across 8 microservices
+  - 100K QPS peak, 99.95% availability
+  - PgBouncer, comprehensive monitoring
+  - 5 DBAs, mature processes
+
+  QuickBill (acquired):
+  - PostgreSQL 14 on self-managed EC2, 8 clusters, 10TB
+  - Organic schema growth, inconsistent naming
+  - 300 tables in a monolithic database
+  - 20K QPS peak, 99.5% availability
+  - No connection pooling, basic monitoring
+  - 1 DBA (the founder who wrote the original schema)
+
+  Integration challenges:
+  1. Schema conflicts: Both have "users", "invoices", "payments" tables
+     with different schemas, different ID formats (UUID vs serial), and
+     overlapping customer IDs
+  2. Data overlap: 2,000 customers exist in both systems — their data
+     must be merged, not duplicated
+  3. Compliance: QuickBill stores PII in plain text; AcmePay encrypts
+     at rest and at column level for SSN/tax IDs
+  4. Versioning: QuickBill on PG 14 needs upgrade to PG 16
+  5. Performance: QuickBill's monolith has 50 queries >10 seconds
+  6. Business continuity: Both products must remain operational during
+     integration — customers of both products are paying
+  7. API contracts: QuickBill's API returns data in different formats;
+     3rd-party integrations depend on these formats
+  8. Regulatory: Financial data retention requirements (7 years) mean
+     historical data must be carefully preserved and mapped
+
+  The CEO's directive: "I want one database, one platform, one team —
+  within 12 months. But we can't lose a single customer or a single
+  dollar of data."
+
+  Task: Write the integration plan. Include: the assessment of both
+  systems (gaps and risks), the schema unification strategy, the data
+  migration plan (handling overlapping customers), the phased timeline,
+  and the risk mitigation plan (what if integration fails mid-way).
+
+assertions:
+  - type: llm_judge
+    criteria: "Schema unification strategy handles conflicts — defines approach for merging users/invoices/payments tables (ID mapping tables, namespace prefixing, or new unified schema), resolves UUID vs serial ID conflict, handles the 2,000 overlapping customers (deduplication strategy with merge rules), and preserves data lineage for regulatory compliance"
+    weight: 0.35
+    description: "Sound schema unification"
+  - type: llm_judge
+    criteria: "Phased timeline is realistic — breaks 12 months into phases (assessment, preparation, parallel run, migration, decommission), ensures business continuity at each phase (both products operational), includes PG 14→16 upgrade and PII encryption remediation for QuickBill data, and identifies dependencies between phases"
+    weight: 0.35
+    description: "Realistic phased timeline"
+  - type: llm_judge
+    criteria: "Risk mitigation addresses business-critical concerns — rollback plan at each phase, data validation (row counts, financial totals, customer record integrity), parallel running period where both systems serve traffic, and a kill switch to halt integration if customer impact is detected. Addresses API compatibility for 3rd-party integrations"
+    weight: 0.30
+    description: "Business-critical risk mitigation"

package/courses/postgresql-query-optimization/scenarios/level-5/database-product-development.yaml

@@ -0,0 +1,72 @@
+meta:
+  id: database-product-development
+  level: 5
+  course: postgresql-query-optimization
+  type: output
+  description: "Build a database performance product — design a SaaS tool that helps teams optimize PostgreSQL performance, from architecture to go-to-market"
+  tags: [PostgreSQL, product-development, SaaS, performance-monitoring, go-to-market, master]
+
+state: {}
+
+trigger: |
+  You're a technical co-founder building a SaaS product for PostgreSQL
+  performance optimization. After 10 years as a DBA, you've seen the
+  same problems at every company. You want to productize your expertise.
+
+  Product vision: "Autopilot for PostgreSQL performance"
+  - Connects to any PostgreSQL database (RDS, Aurora, self-managed)
+  - Analyzes query performance continuously
+  - Recommends and optionally applies optimizations
+  - Provides actionable insights (not just dashboards)
+
+  Competitive landscape:
+  - pganalyze: Query performance monitoring ($500-2,000/mo)
+  - Datadog Database Monitoring: Part of broader APM ($23/host/mo)
+  - New Relic: Database monitoring as part of observability
+  - OtterTune: AI-powered tuning (acquired by AWS)
+  - Percona PMM: Open-source monitoring
+  - pgDash: Simple PostgreSQL monitoring
+
+  Your differentiation: Not just monitoring — actually fixing problems.
+  Every competitor shows you dashboards. You want to show the specific
+  query change, the specific index to add, and optionally apply it.
+
+  Technical challenges:
+  1. Data collection: How to gather query plans, statistics, and
+     performance data with minimal overhead (<1% CPU)
+  2. Analysis engine: How to identify optimization opportunities
+     automatically (unused indexes, missing indexes, query rewrites)
+  3. Safe recommendations: How to ensure recommendations don't break
+     things (test in shadow mode, rollback capability)
+  4. Multi-tenant: Each customer's data is sensitive — isolation required
+  5. Agent vs agentless: Install agent on customer's server vs connect
+     to pg_stat_statements remotely
+
+  Business model options:
+  A. Per-host pricing ($100-500/host/month)
+  B. Per-query pricing (based on optimized queries)
+  C. Value-based pricing (% of infrastructure cost saved)
+  D. Freemium (monitoring free, optimization paid)
+
+  You have $2M seed funding, 6 engineers, and 12 months to get to
+  product-market fit (50 paying customers).
+
+  Task: Write the product strategy. Include: the product architecture
+  (data collection, analysis, recommendation, application), the MVP
+  scope (what to build first for fastest path to 50 customers), the
+  go-to-market strategy (how to reach PostgreSQL teams), the pricing
+  model recommendation, and the technical roadmap (12-month plan).
+
+assertions:
+  - type: llm_judge
+    criteria: "Product architecture is technically sound — data collection uses pg_stat_statements + pg_stat_activity with minimal overhead, analysis engine identifies missing/unused indexes and slow query patterns, recommendations include specific SQL (CREATE INDEX, query rewrites), and the safe application path includes shadow testing and rollback. Multi-tenant data isolation is addressed"
+    weight: 0.35
+    description: "Sound product architecture"
+  - type: llm_judge
+    criteria: "MVP scope is focused on fastest path to customers — identifies the highest-value feature to ship first (likely index recommendations or slow query identification), scopes an MVP achievable in 3-4 months with 6 engineers, explains what to cut from v1 (automated application, multi-database support), and defines clear success metrics for product-market fit"
+    weight: 0.35
+    description: "Focused MVP scope"
+  - type: llm_judge
+    criteria: "Go-to-market and pricing are realistic — identifies target customer profile (mid-size companies with 5-20 PostgreSQL instances, no dedicated DBA), distribution channels (PostgreSQL community, DevOps conferences, content marketing), pricing model is justified against competitors, and the 12-month roadmap has realistic milestones leading to 50 customers"
+    weight: 0.30
+    description: "Realistic GTM and pricing"