Chapter 37 — Quiz

12 questions. Answers at the bottom.

Multiple choice

Q1. The first and biggest factor in choosing a database is usually: - A) Programming language - B) The data's essential model/shape - C) Vendor marketing - D) The logo

Q2. "Be honest about scale" prevents: - A) Slow queries - B) Designing complex systems for traffic you don't have - C) SQL injection - D) Deadlocks

Q3. Strong vs eventual consistency is part of which factor? - A) Cost - B) Consistency requirements (CAP) - C) Ecosystem - D) Query patterns

Q4. Operational complexity matters because: - A) It looks impressive - B) A "better" database your team can't reliably operate is worse than a familiar one - C) It speeds queries - D) It's free

Q5. For most applications, the right default database is: - A) MongoDB - B) PostgreSQL - C) A graph database - D) A vector database

Q6. PostgreSQL covers document/search/spatial/vector needs via: - A) Nothing - B) Extensions (JSONB, FTS, PostGIS, pgvector) - C) Sharding only - D) A separate server each

Q7. Polyglot persistence means: - A) One database for everything - B) Using multiple databases, each for what it's best at - C) No database - D) Only NoSQL

Q8. Healthy polyglot persistence requires: - A) As many databases as possible - B) Each addition justified, PostgreSQL as system of record, minimal sprawl - C) Avoiding PostgreSQL - D) No system of record

Q9. A real-time leaderboard with extreme read speed and eventual consistency suggests: - A) A warehouse - B) Redis (alongside PostgreSQL) - C) A graph database - D) PostGIS

Q10. "Resume-driven development" is: - A) Good practice - B) Choosing a database for trendiness/CV rather than fit — a common mistake - C) A backup strategy - D) Required by GDPR

True/False

Q11. You should try PostgreSQL's extensions before adopting a separate specialized database. (True / False)

Q12. A database decision, once made, can never change. (True / False)

Short answer

Q13. Walk through the framework to choose a database for a typical SaaS app (users, subscriptions, billing).

---

Answer key

Q1 — B. The data's essential model/shape.

Q2 — B. Prevents designing for imaginary scale (premature complexity).

Q3 — B. Consistency requirements (CAP).

Q4 — B. Operability beats theoretical superiority.

Q5 — B. PostgreSQL.

Q6 — B. Extensions (JSONB/FTS/PostGIS/pgvector).

Q7 — B. Multiple databases, each for its strength.

Q8 — B. Justified additions, a system of record, minimal sprawl.

Q9 — B. Redis (with PostgreSQL as source of truth).

Q10 — B. Choosing by fashion/CV, not fit.

Q11 — True. Theme #4 — extensions often suffice, avoiding a new system.

Q12 — False. Revisit on evidence as requirements evolve.

Q13. Data model: highly relational (users↔subscriptions↔invoices with integrity rules) → relational. Workload: OLTP (many small transactional reads/writes). Scale: typically modest — one server + replicas suffices; be honest. Consistency: strong (billing must be correct) → ACID. Query patterns: rich, ad-hoc (reporting, lookups, joins) → SQL. Team/ops & cost: PostgreSQL is mature, free, widely known, managed on every cloud. → PostgreSQL, adding a Redis cache and read replicas as it grows, and a warehouse later if analytics demands it. Every factor points to the relational default.

Scoring: 10–12 you can choose wisely; 7–9 review the framework and theme #4; below 7, redo Exercises C.