9. NoSQL and Multi-Model Databases

Introduction and Context

Relational database management systems remain central to transaction processing, reporting, and analytical workloads. Their tables, foreign keys, schemas, and SQL interfaces provide strong guarantees and a mature foundation for enterprise information systems. However, modern applications increasingly generate data that is large in volume, rapidly changing, geographically distributed, and structurally diverse. Social interactions, sensor streams, user activity, product catalogues, clickstreams, multimedia metadata, and knowledge networks do not always fit naturally into fixed relational tables.

NoSQL databases emerged in response to these pressures. The term does not mean “no SQL” in an absolute sense; it is commonly interpreted as “not only SQL.” NoSQL systems employ alternative data models and distribution strategies to achieve scalability, flexibility, availability, or specialised performance. They are not universally superior to relational systems. Instead, they represent a different set of engineering trade-offs.

A sound database decision therefore begins with workload analysis rather than fashion. The designer must ask what kinds of records are stored, how they are accessed, how much consistency is required, how the system behaves during network failures, and whether the data has relationships, temporal order, or rapidly changing structure. This chapter examines key-value, document, column-family, graph, time-series, and multi-model databases through these questions.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Explain the motivations, characteristics, and terminology of NoSQL databases.

2. Distinguish key-value, document, column-family, graph, and time-series models.

3. Apply CAP, BASE, consistency models, and schema-flexibility concepts to database selection.

4. Evaluate NoSQL technologies according to workload, scalability, availability, and operational requirements.

5. Explain the role and advantages of multi-model databases.

6. Identify technical, governance, security, and professional risks in NoSQL adoption.

7. Recommend an appropriate database approach for realistic organisational scenarios.

From Relational Tables to Distributed Data Models

A relational database represents data through relations, normally implemented as tables. It emphasises normalisation, declarative querying, referential integrity, and transactions with strong ACID properties: atomicity, consistency, isolation, and durability. This model is highly effective when the structure is known, relationships are important, and transactions span multiple entities.

NoSQL systems commonly relax one or more relational assumptions. They may store aggregates rather than decomposed tables, distribute data across many commodity servers, replicate data across regions, or permit records with different attributes. A key design principle is to model data according to access patterns. In a relational design, one often begins with entities and relationships and derives queries. In many NoSQL designs, frequent queries are identified first and the data is organised to serve them efficiently.

This change has important consequences. Denormalisation can reduce joins and improve read performance, but it may create duplicate data. Schema flexibility simplifies evolution, but it can also allow inconsistent records. Horizontal scaling can support very large workloads, but partitioning and replication introduce operational complexity.

CAP and the Reality of Distributed Systems

The CAP theorem states that a distributed data system cannot simultaneously guarantee all three of the following during a network partition:

• Consistency: every successful read receives the most recent applicable write, according to the system’s consistency guarantee.
• Availability: every request to a non-failing node receives a response, although that response may not contain the latest value.
• Partition tolerance: the system continues operating despite communication failures between nodes.

Partition tolerance is not usually optional in a geographically distributed system because network failures can occur. Consequently, a system must make a practical trade-off between consistency and availability when a partition occurs. A consistency-oriented system may reject or delay operations until replicas agree. An availability-oriented system may accept operations and reconcile divergent replicas later.

CAP should not be used as a simplistic label that permanently classifies a product as “CP” or “AP.” Real systems may offer configurable consistency, different guarantees for different operations, and multiple deployment modes. CAP describes behaviour under partition, not ordinary performance or every aspect of database quality.

ACID, BASE, and Consistency Models

Many NoSQL systems are associated with BASE: Basically Available, Soft state, and Eventual consistency. “Basically available” indicates that the system attempts to respond even when some components fail. “Soft state” indicates that the state of replicas may change over time because of asynchronous propagation. “Eventual consistency” means that, if updates stop and communication continues, replicas will eventually converge.

Eventual consistency is not equivalent to random or incorrect behaviour. It is a deliberate guarantee that accepts temporary differences between replicas. It is appropriate for applications such as social-media counters, product recommendations, or replicated content where immediate agreement is less important than availability and latency.

Other useful consistency models include:

• Strong consistency: a read reflects the latest completed write, subject to the system’s formal semantics.
• Linearizability: operations appear to occur atomically in one real-time order.
• Read-your-writes consistency: a client can read its own completed updates.
• Monotonic reads: once a client has seen a value, it does not later observe an older value.
• Causal consistency: causally related operations are observed in an order that preserves their dependencies.
• Session consistency: guarantees such as read-your-writes and monotonic reads are maintained within a client session.

Consistency is therefore a spectrum rather than a binary property. A data architect should specify the minimum guarantee required by each business operation. An account balance, legal record, or inventory reservation may require strong transactional control, whereas a “like” count may tolerate temporary divergence.

The Major NoSQL Models

Key-Value Databases

A key-value database stores a value identified by a unique key. The value may be opaque to the database or may have limited internal structure. Operations are typically simple: put, get, update, and delete.

This model is effective for session data, caching, feature flags, shopping carts, tokens, user preferences, and high-volume lookups. It offers low-latency access and straightforward horizontal partitioning. However, it provides limited query capability. If an application must search by several attributes or perform relationships among values, a key-value store may be unsuitable unless additional indexes or services are introduced.

For example, a session might be represented as `session:7812 → {userId: 44, role: "analyst", expires: ...}`. The key provides direct access, but finding all sessions belonging to a particular role may require a separate index or a different data model.

Document Databases

Document databases store semi-structured records, commonly represented using JSON or a related format. A document may contain nested objects and arrays, allowing an aggregate such as an order and its line items to be stored together. Documents in the same collection may not have identical fields.

Document databases are useful for content management, customer profiles, catalogues, event records, and applications whose structures evolve frequently. They reduce the need for joins when data is naturally accessed as a unit. They also support indexes and expressive queries over document fields.

The flexibility of documents must be governed carefully. If the same concept is represented differently in different documents, analytical queries and application logic become difficult. Validation rules, versioned schemas, migration procedures, and data-quality monitoring remain necessary even when the database does not enforce a rigid schema.

Column-Family Databases

Column-family, or wide-column, databases organise data by row keys and flexible groups of columns. They are designed for distribution across clusters and for workloads involving very large datasets and predictable access paths. A row may contain different columns from another row, and related columns may be grouped into families.

Such systems are appropriate for event logging, telecommunications, recommendation data, large-scale time-indexed records, and workloads requiring high write throughput. Data modelling is strongly query-driven. A designer may create a table specifically for a query such as “retrieve all events for device D during time interval T.”

Wide-column systems are not simply relational tables with more columns. Joins and ad hoc queries are often limited or expensive, and the partition key must be selected carefully. A poor partition key can create hotspots, uneven storage, or partitions that grow without bound.

Graph Databases

Graph databases represent entities as nodes and relationships as edges. Both may contain properties. The model is particularly appropriate when the value of a query depends on traversing relationships rather than merely retrieving isolated records.

Fraud detection, recommendation, identity analysis, network management, knowledge graphs, and access-control analysis are common applications. Queries may ask which accounts share devices, which suppliers are connected through ownership chains, or what products are related through several types of interaction.

Graph databases can express such questions naturally and often avoid the repeated joins required in a relational representation. They are less suitable when the workload consists primarily of simple aggregate reporting over enormous independent records. Graph performance also depends on modelling choices, relationship density, traversal depth, and indexing.

Time-Series Databases

Time-series databases are optimised for measurements associated with timestamps. Examples include temperature, CPU utilisation, energy consumption, financial observations, vehicle telemetry, and application metrics. Their features may include time-based partitioning, compression, retention policies, downsampling, window queries, and high-ingest write paths.

A time-series design must address late-arriving data, clock accuracy, retention, aggregation intervals, and high-cardinality labels. A database that handles millions of measurements efficiently may perform poorly if every event has a unique and unbounded set of dimensions. Time-series systems are often integrated with monitoring and analytics platforms rather than used as general-purpose transactional stores.

Schema Flexibility and Data Governance

Schema-on-write validates structure before data is stored. It provides early error detection and predictable downstream processing. Schema-on-read postpones interpretation until data is queried, enabling rapid ingestion and evolving structures but transferring responsibility to applications and analysts.

NoSQL systems often support schema flexibility, but flexibility is not the same as the absence of design. Professional systems should define required fields, data types, naming conventions, compatibility rules, ownership, and versioning. A useful practice is to maintain a schema registry or validation layer even when the storage engine itself is permissive.

Schema evolution may involve adding optional attributes, introducing a new document version, migrating records in batches, or supporting old and new formats during a transition. Without such practices, technical debt accumulates in the form of undocumented fields, incompatible producers, and unreliable analytics.

Multi-Model Databases

A multi-model database supports more than one data model within a single platform. Depending on the product, it may provide document, graph, key-value, columnar, or relational representations over a common storage and transaction layer.

The motivation is not merely convenience. Organisations often possess data with different structural characteristics. A customer record may be naturally represented as a document, relationships among customers may be analysed as a graph, and behavioural events may require a time-series representation. A multi-model platform can reduce data movement, simplify operations, and support queries that combine perspectives.

Nevertheless, “multi-model” does not guarantee that every model is equally mature. Query languages, indexing, transactions, backup mechanisms, and scaling behaviour may differ across models. A multi-model design should be evaluated for its dominant workloads, not selected solely to avoid operating several technologies.

A Workload-Driven Selection Framework

Technology selection should proceed from requirements to architecture. The following sequence is useful.

First, characterise the workload: read-to-write ratio, request volume, record size, query complexity, latency targets, batch requirements, and expected growth. Second, identify the data shape: aggregates, relationships, measurements, sparse attributes, or simple lookups. Third, establish correctness requirements: which operations require atomicity, isolation, ordering, or immediate visibility? Fourth, define distribution needs, including regions, failure tolerance, recovery objectives, and data residency. Fifth, evaluate operational capabilities such as monitoring, backup, security, staffing, and vendor support.

A summary mapping is helpful:

• Direct lookup with very low latency: key-value.
• Semi-structured aggregates and evolving attributes: document.
• Massive distributed writes with known access paths: column-family.
• Deep relationship traversal: graph.
• Timestamped measurements and retention-based analysis: time-series.
• Several of these workloads with a justified need for shared governance: multi-model.

These mappings are starting points, not automatic answers. A document store may handle time-stamped events, and a relational database may handle graphs through joins. The appropriate choice depends on scale, constraints, team competence, and total cost of ownership.

Applied Case: Fleet Telemetry and Predictive Maintenance

Background

Consider FleetWise, an illustrative logistics company operating delivery vehicles across several regions. Each vehicle produces location data, engine measurements, diagnostic codes, and operational events. The company also maintains driver profiles, vehicle ownership records, maintenance histories, and relationships among depots, routes, and suppliers.

Situation and Problem

The existing relational system stores operational records effectively but struggles with the volume of telemetry. Large append-only tables increase maintenance costs, dashboards experience delays during peak ingestion, and analysts require flexible exploration of new sensor attributes. At the same time, maintenance transactions must remain reliable, and investigators need to trace connections between recurring faults, vehicles, routes, and suppliers.

Analysis

Telemetry is high-volume, timestamped, and commonly queried by vehicle and time interval. It therefore has time-series characteristics. Maintenance work orders involve state transitions, costs, and authorisation, making strong transactional semantics important. Investigative questions involve multiple relationships and may benefit from a graph representation. A single database model is unlikely to be optimal for every operation.

Approach and Strategy

FleetWise adopts a polyglot or multi-model architecture after a workload evaluation. A time-series store receives sensor measurements, applies retention policies, and creates hourly summaries. A transactional relational or strongly consistent document component manages work orders and parts inventory. A graph component represents vehicles, depots, routes, fault codes, and suppliers for investigation. An event-streaming layer distributes changes between services.

The design defines ownership for each data item. The telemetry store is authoritative for measurements; the maintenance system is authoritative for work-order status. Data contracts specify event formats and version compatibility. Strong consistency is required when reserving a part or closing a work order, while delayed consistency is acceptable for dashboards and derived graph views.

Outcome

The architecture separates ingestion from transactional processing and permits each workload to use an appropriate access method. It also introduces additional operational responsibilities: monitoring pipelines, reconciling derived data, securing multiple stores, and testing failure recovery. The benefit comes not from using many technologies automatically, but from matching each technology to a distinct and valuable workload.

Learning Points

The case illustrates four principles. First, database selection should follow access patterns. Second, consistency requirements differ by business operation. Third, polyglot persistence creates integration and governance costs. Finally, a multi-model platform may be preferable when shared administration and cross-model querying outweigh the limitations of using one product.

Risks, Limitations, and Common Mistakes

A frequent mistake is adopting NoSQL because it appears modern or because a benchmark shows high throughput under unrealistic conditions. Benchmarks must reflect the organisation’s data size, query distribution, consistency settings, failure scenarios, and hardware.

Other risks include unsuitable partition keys, hot shards, unbounded documents, uncontrolled duplication, weak transaction boundaries, and insufficient backup testing. Eventual consistency can produce confusing user experiences if the application does not explain or accommodate delayed updates. Data migrations may be harder when records lack a uniform structure.

Security also requires attention. Flexible document fields can accidentally contain personal or confidential information. Access controls should operate at appropriate collection, document, field, or application boundaries. Encryption, key management, audit logging, retention, deletion, and legal discovery must be designed explicitly. Replication across countries may create data-residency and regulatory issues.

Operational teams should monitor replication lag, partition balance, rejected writes, storage amplification, query latency, cache effectiveness, and recovery performance. A database is not highly available merely because it has replicas; failover, backup restoration, and disaster recovery must be tested in practice.

Current Developments and Professional Practice

Cloud-managed NoSQL services increasingly provide automated partitioning, serverless scaling, global replication, and selectable consistency. Distributed SQL systems also narrow the historical boundary between relational and NoSQL databases by combining SQL and ACID transactions with horizontal scaling. Streaming systems and lakehouse architectures further encourage the separation of operational data, event processing, and analytical storage.

Machine learning applications create new requirements for feature retrieval, vector similarity, metadata filtering, and real-time inference. Some databases now combine document or relational capabilities with vector indexing. This development does not eliminate the need for workload analysis: vector search, transactional updates, graph traversal, and time-series ingestion may still have different performance and governance requirements.

Best practice is to begin with a small but realistic workload, define measurable service-level objectives, test failure behaviour, document consistency guarantees, automate deployment, and establish data ownership. Teams should prefer the simplest architecture that satisfies requirements and should treat operational expertise as part of technology selection.

Chapter Summary

NoSQL databases provide alternative models for distributed and heterogeneous workloads. Key-value systems excel at direct lookup, document databases at semi-structured aggregates, column-family systems at large distributed access patterns, graph databases at relationship traversal, and time-series systems at timestamped measurements. Multi-model systems combine several representations but must be assessed for actual workload quality and operational maturity.

CAP explains the trade-off between consistency and availability during network partitions, while BASE and consistency models describe different guarantees for distributed data. Schema flexibility supports evolution but requires validation, versioning, and governance. The correct choice depends on access patterns, scale, latency, consistency, failure tolerance, security, skills, and total cost. A technically successful architecture is therefore one whose data model and guarantees match the organisation’s real decisions and risks.

Key Terms

NoSQL: A family of database systems using non-relational or alternative data models, generally interpreted as “not only SQL.”

Key-value database: A database that retrieves values through unique keys.

Document database: A database that stores semi-structured records containing nested fields and arrays.

Column-family database: A distributed database organised around row keys and flexible groups of columns.

Graph database: A database representing entities as nodes and relationships as edges.

Time-series database: A database optimised for timestamped measurements and temporal queries.

Multi-model database: A database supporting two or more data models within one platform.

CAP theorem: The principle that consistency, availability, and partition tolerance cannot all be guaranteed during a network partition.

Consistency: The guarantee concerning what values a read may observe after writes occur.

Availability: The ability to return a response to requests despite component failures.

Partition tolerance: The ability to continue operating despite communication failures between nodes.

BASE: A distributed-data approach involving basic availability, soft state, and eventual consistency.

Eventual consistency: A guarantee that replicas converge if updates cease and communication continues.

Linearizability: A consistency property in which operations appear to occur atomically in real-time order.

Schema flexibility: The ability for records to have evolving or non-identical structures.

Denormalisation: Deliberate duplication or grouping of data to reduce joins and improve access performance.

Partition key: An attribute used to distribute records among nodes or partitions.

Polyglot persistence: The use of different database technologies for different workloads in one architecture.

Read-your-writes consistency: A guarantee that a client can observe its own completed updates.

Review Questions

Short Answer Questions

1. What problem does a key-value database solve particularly well?

2. Define eventual consistency and state one suitable application.

3. How does a graph database differ from a document database?

4. What is the purpose of a partition key?

5. Why does schema flexibility still require governance?

Long Answer Questions

1. Explain CAP theorem and discuss why its interpretation must focus on behaviour during network partitions.

2. Compare key-value, document, column-family, graph, and time-series databases with suitable applications.

3. Discuss ACID, BASE, and the principal consistency models used in distributed databases.

4. Explain the benefits and risks of multi-model and polyglot persistence architectures.

5. Develop a workload-driven framework for selecting a NoSQL database for an enterprise application.

Analytical / Application Questions

1. A social platform must store user sessions, activity events, friendship relationships, and recommendation data. Recommend suitable database models for each workload and justify the consistency requirements.

2. A retailer wants to use a document database for orders but permits every application team to introduce arbitrary fields. Analyse the risks and propose governance mechanisms.

3. A financial institution wants globally available account balances during network partitions. Evaluate the CAP and consistency implications and recommend questions that must be answered before technology selection.

22. Multiple Choice Questions with Answers

Question 1

A service must retrieve a user session using a unique session identifier with very low latency. Which model is the most direct fit?

A. Graph database

B. Key-value database

C. Time-series database

D. Column-family database

Correct Answer: B. Key-value database

Question 2

During a network partition, a system continues accepting writes but different replicas may temporarily show different values. Which description best fits this behaviour?

A. Availability-oriented operation with eventual consistency

B. Linearizable operation with strong consistency

C. A violation of partition tolerance

D. A guaranteed serializable transaction

Correct Answer: A. Availability-oriented operation with eventual consistency

Question 3

Which workload most strongly justifies a graph database?

A. Storing shopping-cart contents by cart identifier

B. Aggregating CPU measurements by five-minute intervals

C. Finding indirect relationships among accounts, devices, and transactions

D. Appending uniformly structured payroll records

Correct Answer: C. Finding indirect relationships among accounts, devices, and transactions

Question 4

Why can an unsuitable partition key harm a column-family database?

A. It eliminates all schema flexibility

B. It can create hotspots and uneven data distribution

C. It forces every query to use graph traversal

D. It guarantees strong consistency across all replicas

Correct Answer: B. It can create hotspots and uneven data distribution

Question 5

Which statement best describes schema flexibility?

A. It removes the need for validation and data governance

B. It ensures every record has identical attributes

C. It permits evolving structures but still requires controlled conventions

D. It guarantees that analytical queries will remain compatible

Correct Answer: C. It permits evolving structures but still requires controlled conventions

Question 6

A company stores sensor measurements, requiring retention policies, downsampling, and queries by time range. Which database model is most suitable?

A. Time-series

B. Graph

C. Key-value only

D. Document only

Correct Answer: A. Time-series

Question 7

What is a principal advantage of storing an order and its line items as one document?

A. It guarantees that all cross-document joins are free

B. It can retrieve a naturally accessed aggregate without joins

C. It prevents all forms of data duplication

D. It requires a fixed schema for every document

Correct Answer: B. It can retrieve a naturally accessed aggregate without joins

Question 8

Which statement about CAP is most accurate?

A. It says every NoSQL database must sacrifice consistency permanently

B. It concerns trade-offs during network partitions in distributed systems

C. It proves that relational databases cannot be distributed

D. It measures query latency under normal operation

Correct Answer: B. It concerns trade-offs during network partitions in distributed systems

Question 9

In the FleetWise case, why was strong consistency required for parts reservation?

A. Reservations involve a business state where conflicting updates must be controlled

B. Telemetry data cannot be stored asynchronously

C. Graph databases cannot store relationships eventually

D. Time-series databases require serializable transactions

Correct Answer: A. Reservations involve a business state where conflicting updates must be controlled

Question 10

When is a multi-model database a defensible choice?

A. Whenever an organisation wants to avoid analysing workloads

B. When several required data models can be supported effectively with worthwhile operational benefits

C. Only when all data has identical structure

D. When consistency requirements are undefined

Correct Answer: B. When several required data models can be supported effectively with worthwhile operational benefits