Choosing where your data lives

A database is the component that persists data — and the shape of that data drives every choice that follows. Before picking a store, classify what you're storing:

A relational database stores data with relationships in tables of rows and columns, queried with SQL. It's the most widely used type in web development (MySQL, PostgreSQL, SQL Server, MariaDB, Amazon Aurora, Google Cloud SQL). It does three things exceptionally well.

Relationships

It models one-to-one, one-to-many, many-to-many, and many-to-one links. Buy five books from an online store and your customer id C1 links to books B1–B5 — a one-to-many relationship. One row in the customers table maps to many rows in the products table, and pulling C1 tells you exactly what they bought.

Normalization & consistency

Data is stored normalized — each entity lives in exactly one place, in its simplest atomic form, not spread across the database. To update it later, you change one row, not many scattered copies, which keeps the data consistent.

ACID transactions

ACID = Atomicity, Consistency, Isolation, Durability. A transaction executes completely without affecting other processes, and if anything goes wrong mid-way — even a minor failure — the whole operation rolls back. The system moves from a consistent, durable State A to a consistent, durable State B with no middle state; on failure it always returns to State A.

Pick relational when you need strong consistency, transactions, or relationships — stock trading, banking (anything with money), and relationship-heavy social apps. Bonus: a huge community of seasoned engineers, and it's battle-tested. Facebook uses a relational database as its main user-facing DB.

NoSQL databases have no SQL — they're more like JSON-based stores built for Web 2.0 and high-frequency reads and writes (micro-blogging, real-time sports apps, massive multiplayer games). They exist to solve the one thing relational databases struggle with: scaling.

Scaling a relational DB isn't trivial — it must be sharded and replicated to run on a cluster, needing careful planning, human intervention, and skill. NoSQL databases instead add server nodes on the fly and scale with minimal human intervention, running intelligently on clusters with self-healing nodes. The trade-off they accepted to get there: they gave up strong consistency and global ACID transactions, landing on eventual consistency instead.

Pick NoSQL when you need to handle a large volume of read/writes and big data with low latency, want data-model flexibility early in development, can accept eventual over strong consistency, or are running analytics on massive data influx. Popular: MongoDB, Redis, Neo4J, Cassandra, Memcached.

From a benchmarking standpoint, relational and non-relational databases are equally performant. Performance comes from how you design the system, not the technology label — application architecture, database design, bottlenecks, and network latency decide it. Pile on joins in a relational DB and responses slow; strip the complex relationships and joins, and a relational DB is as quick as a NoSQL one.

And you don't have to choose just one — every large-scale service mixes both. That's polyglot persistence, next.

Polyglot persistence means using several distinct persistence technologies together in one application to satisfy its different needs. Design a social network like Facebook and each feature pulls a different store:

The catch: operational complexity — making all these technologies work together in a distributed environment takes real effort to build, manage, and monitor. The shortcut is a multi-model database: a single system that supports multiple data models (graph, document, relational) through one API, cutting the need to run several persistence technologies. Popular multi-model stores: ArangoDB, CosmosDB, OrientDB, Couchbase.

These two models are the heart of distributed data, and the tweet-like-counter makes them concrete. Picture a microblogging site with database nodes in data-center zones across Asia, America, and Europe.

Eventual consistency (optimistic replication)

A user in Japan likes a tweet, pushing the count 100 → 101. At the same instant a user in America still sees 100 — the new value needs time to travel across continents and update those nodes. Refresh a few seconds later and it reads 101. The data was briefly inconsistent but eventually became consistent. The payoff: nodes can be added on the fly, no node needs to be locked, and millions of users can write concurrently — making the system highly available. Fits when accuracy doesn't need to be instant (like counts, live-viewer counts, analytics).

Strong consistency

Every node worldwide holds the same value at all times. The only way to do it is to lock the nodes during an update: when Japan updates 100 → 101, all nodes are locked, the value replicates globally, consensus is reached, then locks lift. Only one user can update at a time; others wait. Fine for a stock-market app where users must never see different prices — but it hits scalability and availability. This locking is what enables ACID transactions.

CAP = Consistency, Availability, Partition tolerance. Partition tolerance means fault tolerance — the system keeps working even when some nodes go offline. The common phrasing is "pick two of three," but the course offers a clearer framing:

• Choose availability: the surviving nodes stay open for writes. But the downed nodes miss those updates, so the system is inconsistent — when they return, they hand back stale values.
• Choose consistency: lock all nodes for writes until the downed ones return, guaranteeing every node holds the same value. But the system isn't fully available meanwhile.

Which you pick depends on the use case. You can't have both at once — nodes spread around the globe take time to reach consensus, and zero latency is impossible.

Document-oriented databases are the leading NoSQL type, storing semi-structured data as independent documents in a JSON-like format. The data model mirrors application-code objects, making storage and querying natural for developers, and it pairs well with Agile because a flexible schema is easy to evolve. Popular: MongoDB, CouchDB, OrientDB, Google Cloud Datastore, Amazon DocumentDB.

Pick a document store when you're working with semi-structured data and a schema that changes often, you're unsure of the schema up front, or you need to scale fast and stay highly available. Being NoSQL, it gives horizontal scalability and fast reads/writes for CRUD use cases with little relational logic. Typical uses: real-time feeds, live sports apps, product catalogs, inventory management, user comments, web-based multiplayer games. Real-world: SEGA (MongoDB for mobile gamers), Wix (MongoDB to host sites).

Graph databases store entities as nodes and relationships as edges — and because those edges are persisted directly, traversing them needs no join-time computation. That's why they're fast: a relational DB computes relationships at query time via joins; a graph DB just fetches the stored edges. Neo4J is the popular example.

Graphs are everywhere. Google Maps is one big graph — cities/places as nodes, roads as edges — and uses shortest-path algorithms (Dijkstra, Bellman-Ford, A*, Floyd–Warshall, Johnson's, Viterbi) to route; Uber and Ola use routing algorithms over it. Flight networks work the same. Google's PageRank treats web pages as weighted nodes and links as edges, ranking higher-weight (more authoritative) pages first.

Pick a graph DB when you need to store complex relationships: social/knowledge/network graphs, AI apps, recommendation engines, fraud analysis, genetic data. Real-world: LinkedIn (LIquid), Uber Eats (graph learning for food discovery), Walmart (Neo4J product recommendations), NASA (Neo4J for "lessons learned" data).

Key-value databases store a value against a unique key and fetch it in constant O(1) time with no query language — just a lookup. The value ranges from a simple string to a complex object graph. That minimum latency makes their primary use case caching, and they're also used to hold consistent state across a distributed system. Popular: Redis, Hazelcast, Riak, Voldemort, Memcached.

Pick a key-value store when you need super-fast fetches with minimum fuss. Typical uses: caching, user state and sessions, real-time data, queues, leaderboards in games, pub-sub systems. Real-world: Twitter (Redis in its infrastructure), Google Cloud (Memcached for caching).

Time-series databases are optimized for data that's continually read and written over time — data points tied to events, tracked and aggregated by business logic. The data streams from IoT devices, self-driving vehicles, industry sensors, social networks, and stock-market feeds. Studying it reveals system behavior, user patterns, and anomalies over time, feeding analytics that drive business decisions. Regular databases aren't built for this; with IoT's rise, time-series stores are increasingly adopted. Popular: InfluxDB, TimescaleDB, Prometheus.

Pick a time-series DB when you manage real-time data continuously over a long period: IoT ingestion, monitoring and analytics, or an autonomous trading platform tracking changing stock prices. Real-world: Uber (M3DB for metrics workflows), Airbnb (Apache Druid for real-time analytics).

Wide-column, column-oriented, and column-family databases are NoSQL stores built for BigData — highly available, scalable, and distributed, mostly avoiding joins to scale read/write performance linearly. Popular: Google Bigtable, Apache Cassandra, HBase. To understand them, start with how data sits on disk.

Row vs. column storage

Row-oriented (MySQL, PostgreSQL) stores each record's fields together in contiguous disk blocks — ideal for OLTP: fetch or update a whole customer easily. Column-oriented (Google BigQuery, Amazon Redshift) stores each column together — ideal for OLAP: to find "% of customers from a country," it scans only the country column instead of traversing billions of full rows, and similar column data compresses well (e.g. run-length encoding). The flip side: inserting a new record touches every column, so writes are costlier. Column-family databases group similar columns into families, with a row spanning multiple families.

Google Bigtable: a column-family store

Bigtable is a distributed column-oriented database scaling to petabytes across thousands of commodity servers, powering 60+ Google products (Earth, Finance, web-search indexing, Analytics). Formally it's "a sparse, distributed, persistent multidimensional sorted map" — sparse meaning most cells are empty. Its key is a (row key, column key, timestamp) tuple and the value is a byte array.

• Row key: for web pages, the reversed URL — maps.google.com/index.html becomes com.google.maps/index.html — so same-domain pages sit in contiguous rows for efficient analytics. Reads/writes under one row key are atomic.
• Columns & timestamps: a page updated over time keeps multiple values under one column key, each with a 64-bit microsecond timestamp, stored newest-first; developers set how many versions to keep, the rest garbage-collected.
• Column families: named family:qualifier; the family must exist before adding a column key. Page content lives under a content family; outbound links under an anchors family. Applied to a customer table: CustomerId as row key, with CustomerInfo and Address as families.

Two cluster architectures

HBase (modeled on Bigtable) uses master-slave: data starts in one region, splits into regions managed by region servers as it grows, the master watches them, and clients ask ZooKeeper which region server holds the data. Cassandra (write-intensive) uses peer-to-peer: every node is identical and runs the same code — giving architectural simplicity, no single point of failure, and add/remove nodes on the fly. Pick a wide-column DB when you're grappling with Big Data and need scalability, performance, and high availability. Real-world: Adobe and others use HBase for large-scale data processing.

The lessons cite many external links. Below are the ones that resolve live today, grouped by topic. Several cited links returned errors and are omitted (noted in the footer).

Relational at scale

Document databases in production

Graph databases in production

Wide-column at scale