The data model is the most consequential decision you make in a system — more consequential than the programming language, more consequential than the cloud provider. A wrong schema choice at 100 users becomes an impossible migration at 100 million users. The schema determines which queries are fast, which are slow, and which are impossible without a rewrite. Most systems that fail at scale fail because of data model decisions made in the first sprint.

In a normalized schema, every fact lives in exactly one place. Updates are simple — change it once. But reads often require joining many tables. In a denormalized schema, data is duplicated to make reads fast. Updates become expensive — change it everywhere. The choice is not "which is better" — it is "which read and write patterns dominate your system."

Polyglot persistence means using different databases for different concerns within one system — each chosen for the access pattern it serves best. A single PostgreSQL instance is the right answer at the start. As the system grows, certain workloads demand purpose-built storage engines that a general-purpose relational database cannot serve efficiently.

Time-series data is the fastest-growing category of data in modern systems. Every metric your servers emit, every reading from an IoT sensor, every financial tick, every user action log — all timestamped events arriving at high velocity. The workload characteristics are unique: writes are append-only, reads are time-range scans, and data value decays over time. General-purpose databases struggle with these patterns. Purpose-built time-series databases exist because this problem is that different.

Every application eventually needs search that goes beyond primary-key lookups and simple WHERE clauses. Full-text search, fuzzy matching, faceted filtering, autocomplete, semantic similarity — your primary data store was not designed for these access patterns. Search is always a secondary index — derived from your primary data but optimized for a completely different query shape. The hard problems are not search itself — they are keeping the search index in sync with the source of truth.

A traditional database index maps a row identifier to its data — given an ID, retrieve the record. An inverted index reverses this: it maps a term to all documents containing that term. This reversal is what makes full-text search fast — look up the term, get the posting list of matching document IDs instantly, no document scanning required.

Hybrid search combines both: keyword matching for exact terms + vector similarity for semantic meaning. Modern search systems weight both signals and merge results. This is the pattern behind modern RAG (Retrieval-Augmented Generation) systems.

Every data system eventually faces the same question: do you process data in large batches at scheduled intervals, or do you process it continuously as it arrives? Batch gives you high throughput and simpler correctness. Stream gives you low latency and real-time insights. Neither is universally better — the choice depends on how fresh your results need to be and what cost you are willing to pay for that freshness.

At some scale, your transactional database cannot serve both operational queries and analytical queries without degrading one or the other. That is when you need a separate analytical system — a data warehouse (structured, fast queries) or a data lake (raw, flexible schema). The modern answer is often a lakehouse that combines the best of both. The decision depends on team maturity, query patterns, and whether you know what questions you will ask before you store the data.

In a distributed data system, consistency is not binary — it is a spectrum. "Strong consistency" and "eventual consistency" are the endpoints, but most real systems operate somewhere in between. The choice is not about technical preference — it is about what your users can tolerate. A banking system that shows a briefly wrong balance creates real financial harm. A social media feed that is 2 seconds stale creates zero harm. Both are valid consistency choices — for their context.

In eventually consistent systems, concurrent writes to the same record will conflict. You need a resolution strategy decided at design time — not discovered at incident time.