Imagine you own a toy shop. Every day you write down which toy was sold, to whom, and for how much. At first, a single notebook works. But as the shop grows into ten shops, one notebook is no longer enough — you need a proper filing system with clear pages, columns, and rules about what can be written where. A database is exactly that: a filing system for a computer program, engineered so that data can be stored, found, changed, and trusted — even years later, and even when thousands of people are using it at the same instant.

SQL databases (also called relational databases or RDBMS — Relational Database Management Systems) are the “notebook with strict, printed columns” approach. Every page (called a table) has the same fixed columns, and every row must obey the same shape.

NoSQL databases are the “flexible folder” approach. Instead of forcing every record into identical columns, each item can carry its own structure — some folders have five sheets of paper, others have fifty, and that’s allowed.

1.1 · A short history

In 1970, an IBM mathematician named Edgar F. Codd published a paper describing data as relations — mathematical tables. That paper became the theoretical seed of the relational model. Companies then built real systems on top of that idea: IBM’s System R and, more famously, Oracle (1979), followed by Microsoft SQL Server, MySQL (1995), and PostgreSQL (1996). The language used to talk to these systems was eventually standardised as SQL — Structured Query Language — by ANSI in 1986.

For roughly three decades, “database” basically meant “relational database.” Then, between 2000 and 2010, the internet exploded in scale. Companies like Google, Amazon, Facebook, and Twitter had so many users and such fast-changing, unpredictable data (photos, likes, friend graphs, sensor logs) that rigid tables became a bottleneck. Google published the Bigtable paper (2006) and Amazon published the Dynamo paper (2007). Those papers inspired a new wave of databases — MongoDB (2009), Cassandra (2008), Redis (2009), Neo4j (2007) — that deliberately broke the “every row must match” rule in exchange for speed and flexibility at massive scale. The umbrella term NoSQL (“Not Only SQL”) was popularised around 2009 to describe this new family.

Today, both families are fully mature, both are used in production at enormous scale, and the real skill is not “which one is better” — it is knowing which tool fits which job, and often using both together inside the same application (that combination is called polyglot persistence, which we cover in Section 15).

1. 1970 · Codd’s relational paper

   Edgar F. Codd (IBM) formalises data as relations — the mathematical foundation of every SQL database that followed.

2. 1979 onwards · commercial RDBMS era

   Oracle, DB2, Sybase, SQL Server, MySQL and PostgreSQL turn the relational model into the default way to store business data.

3. 1986 · SQL becomes an ANSI standard

   Structured Query Language is standardised, so knowledge transfers cleanly from one relational engine to another.

4. 2006 – 2007 · Bigtable and Dynamo papers

   Google and Amazon publish influential papers describing databases built to scale across thousands of ordinary machines.

5. 2007 – 2009 · NoSQL goes mainstream

   Neo4j, Cassandra, MongoDB, and Redis are released; the “NoSQL” label sticks after a 2009 San Francisco meetup.

6. 2010 — today · blended world

   Managed cloud NoSQL services (DynamoDB, Cosmos DB, Firestore) and newer distributed SQL databases (Spanner, CockroachDB, YugabyteDB) blur the line: modern engineers use both together.

A running computer program keeps its data in memory (RAM), which is extremely fast but is wiped clean the moment the program stops or the machine restarts. That is not good enough for anything you care about — a bank balance, a chat message, a hospital record.

A database solves four problems at once:

• Durability — data survives crashes, power loss, and restarts, usually by writing to disk.
• Structure & querying — you can ask meaningful questions (“find all orders above ₹500 from Mumbai last week”) instead of scanning raw files by hand.
• Concurrency — many users can read and write at the same time without corrupting each other’s data.
• Integrity — rules are enforced, e.g. an order can’t reference a customer that does not exist.

SQL emerged to solve the “structure and integrity” problem extremely well. Banks, airlines, hospitals, and payroll systems all need every record to be trustworthy and consistent, and they were willing to trade some flexibility and raw write-speed for that guarantee.

NoSQL emerged to solve a different, newer problem: “we have too much data, too many simultaneous users, and our data shape keeps changing — please don’t slow us down with rigid rules.” Social networks, IoT sensor streams, product catalogs, and real-time recommendation engines were the first heavy adopters.

3.1 · What is a relational (SQL) database?

A relational database stores data in tables. A table is like a spreadsheet:

• Each table has a fixed set of columns (also called fields) — e.g. id, name, email.
• Each row (also called a record or tuple) is one entry — one customer, one order.
• Every row in a table must have a value (or an explicit “empty”/NULL) for every column, in the same order and same data type.
• Tables are linked using keys: a primary key uniquely identifies a row (like a passport number), and a foreign key in one table points to the primary key of another table, creating a relation between them — hence the word “relational.”

3.2 · What is SQL, the language?

SQL is the language you use to talk to a relational database. It reads almost like English:

SELECT name, city
FROM customers
WHERE city = 'Pune'
ORDER BY name;

This says: “go to the customers table, find rows where city is Pune, and give me just the name and city columns, sorted by name.” SQL has four broad sub-languages you’ll hear about:

• DDL (Data Definition Language) — CREATE TABLE, ALTER TABLE, DROP TABLE: defines the structure.
• DML (Data Manipulation Language) — INSERT, UPDATE, DELETE: changes the data.
• DQL (Data Query Language) — SELECT: reads the data.
• DCL (Data Control Language) — GRANT, REVOKE: controls who can do what.

3.3 · What is a NoSQL database?

“NoSQL” is not one single technology — it is an umbrella term for four major families, each storing data very differently:

{
  "_id":  "c001",
  "name": "Aria",
  "city": "Pune",
  "pets": ["cat", "parrot"]
}

3.4 · The core philosophical difference

SQL says: “Decide the shape of your data up front (this is called a schema), and I will enforce it strictly, forever, for every row.” This is called schema-on-write.

NoSQL (mostly) says: “Store whatever shape you give me now, and figure out how to read it later.” This is called schema-on-read — the structure is applied by the application when it reads the data, not enforced by the database when it writes.

4.1 · Inside a relational database engine

A typical RDBMS (like PostgreSQL or MySQL) has these major components:

• Connection manager — accepts client connections (your Java app, your web server) and hands each one a session.
• Query parser — reads your SQL text and checks it is grammatically valid.
• Query optimizer / planner — decides the fastest way to execute your query (which index to use, which table to scan first).
• Execution engine — actually runs the chosen plan, row by row or in batches.
• Storage engine — reads and writes actual bytes to disk, manages indexes, and enforces the on-disk data format. MySQL famously lets you choose the storage engine (InnoDB, MyISAM).
• Transaction manager / lock manager — makes sure concurrent operations don’t corrupt each other (more in Section 6).
• Write-Ahead Log (WAL) — an append-only log of every change, written before the actual data pages, used for crash recovery.

4.2 · Inside a NoSQL cluster

Most NoSQL systems are designed to run as a cluster of many machines (nodes) from day one, rather than one big machine. A typical wide-column or document cluster (like Cassandra or MongoDB) has:

• Nodes — individual machines, each holding a slice (partition) of the total data.
• Partitioner / shard router — decides, using a hash of the key, which node owns which piece of data.
• Replication manager — copies each piece of data onto multiple nodes so that losing one machine doesn’t lose the data.
• Coordinator node — the node a client happens to talk to, which forwards the request to the right owner node(s) and merges the responses.
• Gossip / membership protocol — nodes constantly tell each other “I’m alive,” so the cluster can detect a dead node quickly.

5.1 · Indexing — how a database finds a row instantly

Without an index, finding a row means scanning every single row — like reading every page of a book to find one sentence. This is called a full table scan and is slow for large tables.

An index is a separate, sorted structure that lets the database jump almost straight to the answer. Most relational databases use a data structure called a B-Tree (Balanced Tree) for indexes.

A B-Tree keeps keys sorted and balanced, so a lookup, insert, or delete takes O(log n) time — for a million rows, that’s roughly 20 comparisons instead of a million. Most SQL primary keys, and any column you add an INDEX to, are stored this way.

NoSQL systems use indexing too, but often add a second structure: a hash index, which is extremely fast for exact-match lookups (O(1) on average) but useless for range queries (“find everything between A and M”) because a hash scrambles the order. Wide-column stores like Cassandra use a combination of an in-memory sorted structure called a memtable plus on-disk sorted files called SSTables (Sorted String Tables), merged together using an algorithm called an LSM-Tree (Log-Structured Merge-Tree).

5.2 · How writes actually happen (Write-Ahead Logging)

To be durable, a database cannot just update its data files directly and hope for the best — if the power fails mid-write, the file could be half-corrupted. Instead, most databases (both SQL and many NoSQL) follow this pattern:

1. Append to the log first

   The change is appended to a sequential log file (WAL, or in Cassandra’s case, a “commit log”).

2. Acknowledge the client

   Once the log write is confirmed on disk, the database tells the client “success.”

3. Update the in-memory structure

   The actual data structure (table pages, or the LSM memtable) is updated, possibly slightly later, in memory first.

4. Flush to disk in the background

   Periodically, the in-memory structure is flushed to disk as a proper data file.

If the machine crashes between steps 3 and 4, the database simply replays the log on restart to rebuild the lost in-memory state. This single idea — “log first, apply later” — is one of the most important concepts in all of database engineering, and it is shared by SQL and NoSQL systems alike.

5.3 · Normalization vs Denormalization

Normalization is a SQL design discipline that splits data into many small, non-repeating tables to avoid storing the same fact twice. There are formal levels called Normal Forms (1NF, 2NF, 3NF, BCNF), but the beginner-friendly summary is: “each fact should live in exactly one place.”

Denormalization is the opposite: deliberately duplicating data to avoid expensive joins later. NoSQL databases lean heavily into denormalization because they are often optimised for very fast reads of one document, even if that means storing the same customer name inside a thousand order documents.

A transaction is a group of operations that must all succeed together, or all fail together — there is no “half done” state. The classic example is a bank transfer: money must leave account A and arrive in account B as a single, indivisible unit.

6.1 · ACID — the SQL promise

Relational databases are famous for guaranteeing ACID properties:

• Atomicity — all steps in a transaction happen, or none do.
• Consistency — a transaction moves the database from one valid state to another valid state, never breaking a defined rule (like a foreign key or a “balance cannot go negative” constraint).
• Isolation — transactions running at the same time don’t see each other’s half-finished work.
• Durability — once a transaction is confirmed, it survives a crash.

BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE id = 'A';
UPDATE accounts SET balance = balance + 500 WHERE id = 'B';
COMMIT;

If the second UPDATE fails for any reason, the database automatically rolls back the first one too — money is never lost or duplicated.

6.2 · BASE — the typical NoSQL promise

Many (not all) NoSQL databases favour BASE instead, trading strict correctness for speed and availability at large scale:

• Basically Available — the system almost always responds, even during partial failures.
• Soft state — the data might be changing or settling in the background even without new input (due to replication).
• Eventual consistency — if you stop writing, all replicas will eventually agree on the same value, but not necessarily instantly.

This is a real trade-off, not a flaw. A “like” count that is off by one for half a second is harmless. A bank balance that is off by ₹500 is not. This is exactly why the two families were designed with different priorities.

The CAP theorem, formalised by Eric Brewer, is one of the most quoted ideas in distributed systems. It says that when a database is spread across multiple machines connected by a network, and that network can fail (a partition), the system can only guarantee two of these three properties at once:

• Consistency (C) — every read gets the most recent write, or an error. Everyone always sees the same, up-to-date data.
• Availability (A) — every request gets a (non-error) response, even if it might not be the newest data.
• Partition tolerance (P) — the system keeps working even if network messages between nodes are lost or delayed.

Since a network partition is unavoidable in any real distributed system (P is not really optional), the practical choice in production is between CP (favour correctness, pause on partition) and AP (favour uptime, allow temporary disagreement).

7.1 · Consistency models, in plain terms

Most modern NoSQL systems let you dial this per operation. For example, Cassandra lets you request ONE (fast, least safe), QUORUM (majority of replicas agree, balanced), or ALL (every replica must agree, slowest, safest) for each individual read or write.

8.1 · SQL: strengths and weaknesses

8.2 · NoSQL: strengths and weaknesses

8.3 · Side-by-side comparison

9.1 · Vertical vs Horizontal scaling

Vertical scaling (scale up) means giving one machine more CPU, RAM, or faster disks. Horizontal scaling (scale out) means adding more machines and spreading the load across them.

Traditional SQL databases were built assuming one strong machine, because ACID transactions and joins are much easier to guarantee when all the data is in one place. NoSQL databases were designed from the start assuming many ordinary machines working together, which is exactly why they dominate at internet scale.

9.2 · Sharding (Partitioning)

Sharding means splitting one huge dataset into smaller pieces (shards), each living on a different machine. A partition key (or shard key) — often a hash of the user ID or a similar identifier — decides which shard a piece of data belongs to.

Sharding is possible in SQL too (e.g. Vitess for MySQL, Citus for PostgreSQL, or native sharding in Google Spanner and CockroachDB), but it is significantly harder because joins and transactions that span shards become expensive network operations. NoSQL databases were designed around the assumption that most queries touch only one shard, which is why sharding feels much more natural there.

9.3 · Read replicas & caching

Both families commonly use read replicas — extra copies of the data that only serve reads, letting the primary machine focus on writes. A very common performance pattern, regardless of database type, is putting a fast key-value cache (like Redis) in front of the database to absorb repeated reads (covered more in Section 14).

9.4 · Big-O intuition for common operations

10.1 · Replication strategies

• Single-leader (primary-replica) replication — one node accepts writes, and pushes changes to one or more read-only replicas. Simple, used by default in PostgreSQL, MySQL, and MongoDB (replica sets).
• Multi-leader replication — multiple nodes accept writes, and changes are synced between them. Useful across data centres, but requires conflict resolution when the same record is edited in two places at once.
• Leaderless replication — any node can accept a write, and the client (or a coordinator) contacts multiple replicas directly, resolving conflicts using timestamps or version vectors. This is how Cassandra and DynamoDB work.

10.2 · Failover

Failover is the process of automatically promoting a replica to be the new leader when the old leader dies, so the system keeps working. Tools like Patroni (PostgreSQL), MySQL Group Replication, and MongoDB’s built-in replica-set elections handle this automatically in modern setups. This usually causes a brief write outage (seconds) while a new leader is elected.

10.3 · Consensus algorithms

How do multiple machines agree on “who is the leader” or “what is the true, agreed order of operations” — especially when messages can be lost or delayed? This is solved by consensus algorithms:

• Paxos — the original, famously difficult-to-understand consensus algorithm, still used inside systems like Google Chubby and Spanner.
• Raft — designed specifically to be easier to understand and implement than Paxos. It works by electing a leader through majority voting, and the leader then replicates a log of commands to followers. Raft is used inside etcd, Consul, CockroachDB, and MongoDB’s replica-set elections.

10.4 · Backup & disaster recovery

• Full backups — a complete snapshot of the database at a point in time.
• Incremental / WAL-based backups — only the changes since the last backup, replayed on top of a base snapshot (much faster and cheaper).
• Point-in-time recovery (PITR) — using the WAL / log to restore the database to any exact second, e.g. “just before the bad deployment ran a destructive script.”
• Multi-region replication — keeping a live copy in a different geographic region, so a regional outage (or even a natural disaster) doesn’t take down the whole service.

The two standard metrics for disaster recovery planning are: RPO (Recovery Point Objective) — how much data you can afford to lose (measured in time), and RTO (Recovery Time Objective) — how long you can afford to be down.

11.1 · Authentication & authorization

• Authentication — proving who you are (username / password, certificates, IAM roles in cloud databases).
• Authorization — controlling what an authenticated user is allowed to do. SQL databases have a mature role-based access control (RBAC) model with GRANT / REVOKE down to the column level. NoSQL databases increasingly support similar role systems (e.g. MongoDB roles, Cassandra’s role-based permissions).

11.2 · Encryption

• Encryption in transit — TLS between the application and the database, so nobody sniffing the network can read queries or results.
• Encryption at rest — data files on disk are encrypted, so a stolen hard drive is useless without the key.
• Field-level encryption — specific sensitive fields (like a credit card number) are encrypted even from database administrators, common for compliance like PCI-DSS.

11.3 · Injection attacks

SQL Injection is one of the oldest and most dangerous web vulnerabilities. It happens when user input is pasted directly into a SQL string instead of being safely parameterised:

// DANGEROUS - never do this
String query = "SELECT * FROM users WHERE username = '" + userInput + "'";

If a user types ' OR '1'='1, the query becomes ... WHERE username = '' OR '1'='1' — always true, potentially returning every row. The fix is parameterised queries / prepared statements, shown in Section 17.

NoSQL databases are not immune — NoSQL injection is a real category too, where crafted JSON operators (like MongoDB’s $where or $ne) are injected through unsanitised input to bypass authentication logic. The defense principle is identical: never build a query by concatenating raw, untrusted user input — always use the driver’s safe parameter-binding features.

11.4 · Least privilege & auditing

A production application should connect to the database with a role that has only the permissions it actually needs (e.g., a reporting service should not have DELETE rights). Audit logging records who did what and when, which is essential for compliance (GDPR, HIPAA, SOC 2) and for investigating incidents after the fact.

12.1 · Metrics to watch

12.2 · Tools commonly used

Prometheus + Grafana dashboards, Datadog, New Relic, and cloud-native tools (Amazon RDS Performance Insights, MongoDB Atlas monitoring, DataStax OpsCenter for Cassandra) are the common choices. Slow-query logs (EXPLAIN ANALYZE in PostgreSQL, .explain() in MongoDB) reveal exactly which queries need an index or a rewrite.

12.3 · Distributed tracing

In a microservices architecture, one user click might trigger ten downstream calls, several touching the database. Distributed tracing (using tools like OpenTelemetry, Jaeger, or Zipkin) attaches a unique trace ID to a request as it flows through every service and database call, so engineers can see exactly where time was spent.

• Managed database services — the cloud provider handles patching, backups, and failover. Examples: Amazon RDS & Aurora (SQL), Amazon DynamoDB (NoSQL), Google Cloud SQL & Spanner, Azure SQL Database, MongoDB Atlas, Redis Cloud.
• Containers & Kubernetes — running databases as StatefulSets with persistent volumes, often used for self-managed setups or hybrid clouds. Operators like the Zalando PostgreSQL Operator or the MongoDB Kubernetes Operator automate day-2 tasks (backups, scaling, failover).
• Serverless databases — scale automatically to zero and back up, billed per request rather than per running server (e.g., DynamoDB On-Demand, Aurora Serverless, Neon for Postgres).
• Multi-region deployment — many modern databases support active-active or active-passive replication across regions for lower latency and disaster resilience — at the cost of embracing eventual consistency between regions.

13.1 · Cost considerations

SQL databases traditionally cost more to scale (bigger machines get expensive fast, and licensing for systems like Oracle / SQL Server can be significant). NoSQL databases often bill by request / throughput and storage, which can be cheaper at huge scale but surprising if access patterns are inefficient (for example, scanning instead of using the partition key). A common cost-optimisation habit is right-sizing instances, enabling auto-scaling only where truly needed, and archiving cold or rarely-accessed data to cheaper storage tiers.

A cache (very often Redis or Memcached — themselves key-value NoSQL stores) sits between the application and the database, keeping frequently-requested results in memory. This is why the line between “database” and “caching layer” is blurry: Redis is technically a NoSQL database, but is most often deployed specifically as a cache.

14.1 · Common cache patterns

• Cache-aside (lazy loading) — the app checks the cache first; on a miss, it reads the database and then writes the result into the cache.
• Write-through — every write goes to the cache and the database at the same time, keeping them always in sync.
• Write-behind — writes land in the cache first and are asynchronously flushed to the database later, trading some durability for speed.

A load balancer distributes incoming requests across multiple application servers (and sometimes directly across read replicas), preventing any single machine from being overwhelmed, and enabling horizontal scaling of the stateless application layer while the stateful database layer scales separately using the replication / sharding techniques from Section 9.

15.1 · Good patterns

• Polyglot persistence — using different databases for different parts of the same application, based on their strengths: PostgreSQL for orders and payments (needs ACID), Redis for session / cache, Elasticsearch for search, Neo4j for a recommendation graph.
• CQRS (Command Query Responsibility Segregation) — using a write-optimised model (often SQL) for commands, and a separate, denormalized read-optimised model (often NoSQL or a search index) for fast queries, kept in sync by events.
• Embedding vs Referencing (NoSQL modeling) — embed related data inside one document when it is always read together and rarely changes independently (e.g., an address inside a user profile); reference (store an ID and look it up separately) when the related data is large, shared, or updated independently (e.g., a product referenced by thousands of orders).
• Database-per-service — in microservices, each service owns its own database, and other services never query it directly, only through the service’s API. This keeps services independently deployable.

15.2 · Anti-patterns to avoid

• Using MongoDB (or any NoSQL) like a relational database — manually simulating joins with multiple round-trip queries in application code, without ever using embedding or denormalization, throws away the main benefit of the document model.
• Storing everything in one giant unindexed table / collection — regardless of SQL or NoSQL, forgetting to index the fields you actually query on leads to full scans and terrible performance as data grows.
• Over-normalising in a system that needs raw speed — chasing “perfect” normalization in a read-heavy, high-traffic table can force expensive joins where a bit of denormalization would have been far cheaper.
• Ignoring the access pattern when choosing a partition / shard key — a poorly chosen shard key creates “hot partitions,” where one node gets overloaded while others sit idle.
• Treating eventual consistency as “no consistency” — assuming a NoSQL database is always instantly consistent when it explicitly is not, leading to subtle bugs like a user not seeing their own just-posted comment.
• Choosing a database because it’s trendy — picking MongoDB or Cassandra just because a big company uses it, without checking if your actual access pattern and consistency needs match, is a common and costly mistake.

16.1 · General — applies to both

• Always use parameterised queries / prepared statements — never string-concatenate user input.
• Design your schema (or document shape) around how the data will be queried, not just how it looks conceptually.
• Add indexes deliberately, and remove unused ones — every index speeds up reads but slows down writes and costs storage.
• Set connection pool limits sensibly; an unbounded pool can crash a database under load.
• Test failover and backups regularly — a backup you have never restored is not a real backup.
• Monitor before you need to; set alerts on latency and error-rate thresholds, not just “is it down.”

16.2 · SQL-specific

• Use EXPLAIN / EXPLAIN ANALYZE before assuming a slow query needs a bigger machine.
• Avoid SELECT * in production code — fetch only the columns you need.
• Keep transactions short — long transactions hold locks and block other users.
• Use migrations (tools like Flyway or Liquibase) instead of manually editing schema in production.

16.3 · NoSQL-specific

• Choose your partition / shard key based on your most common query, not on convenience.
• Understand your database’s default consistency level — don’t assume it’s strong unless you’ve checked.
• Watch document / row size limits (e.g., MongoDB documents cap at 16 MB) — don’t let a document grow unbounded.
• Version your document schema even without an enforced schema, so old and new shapes can coexist safely as the app evolves.

17.1 · SQL — safe querying with JDBC

// Using a parameterized (prepared) statement prevents SQL injection.
String sql = "SELECT id, name, city FROM customers WHERE city = ?";

try (Connection conn = DriverManager.getConnection(url, user, pass);
     PreparedStatement stmt = conn.prepareStatement(sql)) {

    stmt.setString(1, "Pune");              // safely bound, never concatenated

    try (ResultSet rs = stmt.executeQuery()) {
        while (rs.next()) {
            System.out.println(rs.getInt("id") + " "
                + rs.getString("name"));
        }
    }
}

The ? placeholder is filled in safely by the driver — user input can never change the shape of the query, which is exactly how SQL injection (Section 11.3) is prevented.

17.2 · SQL — a transaction (bank transfer)

try (Connection conn = DriverManager.getConnection(url, user, pass)) {
    conn.setAutoCommit(false);          // start a manual transaction

    try (PreparedStatement debit = conn.prepareStatement(
            "UPDATE accounts SET balance = balance - ? WHERE id = ?");
         PreparedStatement credit = conn.prepareStatement(
            "UPDATE accounts SET balance = balance + ? WHERE id = ?")) {

        debit.setBigDecimal(1, amount); debit.setString(2, "A");
        credit.setBigDecimal(1, amount); credit.setString(2, "B");

        debit.executeUpdate();
        credit.executeUpdate();

        conn.commit();                    // both succeed together
    } catch (Exception e) {
        conn.rollback();                  // or neither happens
        throw e;
    }
}

17.3 · NoSQL — MongoDB document insert & query

MongoClient client = MongoClients.create("mongodb://localhost:27017");
MongoDatabase db = client.getDatabase("shop");
MongoCollection<Document> customers = db.getCollection("customers");

// Insert a flexible document - no fixed columns required
Document aria = new Document("_id", "c001")
        .append("name", "Aria")
        .append("city", "Pune")
        .append("pets", List.of("cat", "parrot"));
customers.insertOne(aria);

// Query, safely using the driver's filter builders (no string concatenation)
for (Document doc : customers.find(Filters.eq("city", "Pune"))) {
    System.out.println(doc.toJson());
}

17.4 · NoSQL — Redis as a cache-aside layer

Jedis redis = new Jedis("localhost", 6379);

String cacheKey = "customer:" + id;
String cached = redis.get(cacheKey);

if (cached != null) {
    return cached;                       // cache hit - no database call at all
}

String fresh = fetchCustomerFromSql(id);   // cache miss - go to the source of truth
redis.setex(cacheKey, 300, fresh);      // store for 300 seconds
return fresh;

This is the cache-aside pattern from Section 14, combining a NoSQL key-value store (Redis) in front of a SQL system of record — a perfect illustration of polyglot persistence in a single small function.

19.1 · Key takeaways

• SQL — fixed schema, tables, ACID transactions, joins, mature tooling.
• NoSQL — flexible schema, four families (document, key-value, wide-column, graph), horizontal scale, often eventual consistency.
• Both use durability techniques like write-ahead logging under the hood.
• CAP theorem — during a network partition, pick consistency or availability; you cannot fully have both.
• Indexing (B-Trees for SQL, LSM-Trees for many NoSQL writes) is what makes both fast at scale.
• Production systems commonly combine both — polyglot persistence, not “one database to rule them all.”
• Security fundamentals (parameterised queries, encryption, least privilege) apply to both equally.
• The right choice depends on your data shape, consistency needs, and access patterns — not on trends.