Database

Relational/NoSQL database design — schema, indexing, query patterns for the core Postgres backend. Sharding/replication live here too, from the DB-engine-configuration angle — see ConsistencyConcurrency/ for the correctness/distributed-systems angle on the same concepts.

Why we need this / what value this brings

Schema and indexing decisions made early are the hardest and most expensive to change once real data and query patterns exist.

When to use this

At the start of any new feature that introduces new data — retrofitting indexes/schema onto a live table is riskier than designing them upfront.

How to use or implement this

Design tables and indexes around the actual queries the app will run, not a theoretical normalized ideal; add indexes where query plans show they're needed.

Subtopics

• Indexing
• Replication
• RowVersioning OptimisticConcurrency
• SQL vs NoSQL
• SchemaDesign Normalization
• Sharding

Research questions

• Are the booking/service/provider tables indexed for the actual query patterns the frontend uses (see backend/ migrations)?

---

Empty folder — drop notes, links, and findings here as you research.