Choosing the Right NoSQL Database for Your Application: Use Cases and Recommendations

This article is translated from "35+ Use Cases For Choosing Your Next NoSQL Database" and examines which database systems fit different use cases.

Document Databases

Origin: Inspired by Lotus Notes.

Data model: Collections of key‑value documents.

Examples: CouchDB, MongoDB.

Advantages: Natural data model, developer‑friendly, rapid web‑oriented CRUD development.

Graph Databases

Origin: Euler and graph theory.

Data model: Nodes and relationships (also can handle key‑value pairs).

Examples: AllegroGraph, InfoGrid, Neo4j.

Advantages: Solves complex graph problems.

Relational Databases

Origin: Proposed by E. F. Codd.

Data model: Various relational schemas.

Examples: VoltDB, Clustrix, MySQL.

Advantages: High‑performance, scalable OLTP, SQL support, materialized views, transactions, developer‑friendly.

Object Databases

Origin: Research on graph databases.

Data model: Objects.

Examples: Objectivity, Gemstone.

Advantages: Complex object models, fast key‑value access, graph‑like capabilities.

Key‑Value Databases

Origin: Amazon's Dynamo paper and Distributed Hash Tables.

Data model: Simple key‑value pairs.

Examples: Membase, Riak.

Advantages: Handles massive data volumes, fast read/write, developer‑friendly.

BigTable‑type Databases

Origin: Google’s BigTable paper.

Data model: Column families with flexible rows.

Examples: HBase, Hypertable, Cassandra.

Advantages: Handles huge data, high write load, high availability, cross‑datacenter support, MapReduce integration.

Data‑Structure Services

Origin: Unknown.

Data model: Dictionaries, lists, sets, strings.

Examples: Redis.

Advantages: Offers data structures not found in traditional databases.

Grid Databases

Origin: Data grid and tuple‑space research.

Data model: Space‑based architecture.

Examples: GigaSpaces, Coherence.

Advantages: High‑performance, highly scalable transaction processing.

What Should Your Application Use?

Identify the required data model and product features; choose the database that best matches both.

Refer to "What The Heck Are You Actually Using NoSQL For?" for diverse unconventional scenarios.

Match product capabilities to your needs; the distinction between NoSQL and SQL is secondary.

Consider both data model and product characteristics; no single model decides the choice.

Select the product that offers the features you need most.

Sample Application Requirements and Recommendations

For complex transactions requiring ACID guarantees, consider relational or grid databases (e.g., inventory systems).

For scalability, any database that supports horizontal scaling, sharding, load balancing, and fault tolerance.

For high availability with eventual consistency, BigTable‑type databases are suitable.

For high‑throughput read/write workloads, document, key‑value, or in‑memory databases (e.g., Redis) are appropriate.

For social networking graphs, graph databases are the first choice; key‑value stores like Riak or in‑memory relational databases can also work.

Additional Scenarios

When flexible access patterns and data types are needed, document databases excel.

For large‑scale offline analytics, consider Hadoop or other MapReduce‑enabled platforms.

For multi‑datacenter deployments, choose BigTable‑model products that handle latency and partition tolerance.

CRUD‑centric applications benefit from document databases to avoid joins.

Search workloads can use Riak.

For lists, sets, queues, pub/sub, and distributed locks, Redis is a strong candidate.

For JSON/HTTP/REST‑friendly development, document and key‑value databases are ideal.

Further Considerations

For real‑time transactional materialized views, VoltDB is recommended.

For enterprise support contracts, products like Membase may be considered.

For continuous massive data ingestion with relaxed consistency, BigTable‑type databases are suitable.

For simple PaaS solutions, choose a managed service that requires minimal operational effort.

For enterprise customers accustomed to relational databases, stick with relational solutions.

For dynamic object relationships without a fixed schema, graph databases are appropriate.

For large binary objects, storage services like S3 are preferable; NoSQL databases are not ideal for BLOBs.

Performance and Migration Insights

Moving to NoSQL solely for a 25% performance gain is rarely justified.

Benchmark results are scenario‑specific and may not reflect your workload.

Start‑up teams with no legacy system may experiment with either SQL or NoSQL.

Performance differences diminish with small data volumes but grow with scale.

Every product has issues; evaluate whether you can address them.