What Is NoSQL and When Should You Use a NoSQL Database?

Updated

NoSQL is an umbrella term for database systems that store and query data without the fixed table-and-row model of a relational database. You should consider one when your data shape varies a lot, when you need to spread writes across many machines, or when you are storing documents, key lookups, or highly connected records. You should stay with a relational database when your data is well structured, your queries depend on multi-table joins, and you need strong transactional guarantees across many records.

The main NoSQL families

"NoSQL" is not one technology. The four families below solve different problems, and choosing the wrong one is the most common mistake.

Type Data model Typical fit Example of a concrete task
Document Self-contained documents (often JSON or XML) with nested fields Content stores, catalogs, CMS-like sites Storing archival records where each item has different metadata fields
Key-value A key mapped to an opaque value Sessions, caches, simple lookups Looking up a user session by token in one read
Wide-column Rows with flexible column families, partitioned by key High-volume time-series or event data Writing millions of sensor readings per day
Graph Nodes and edges as first-class objects Connected data, recommendations, lineage Finding all documents that cite a given manuscript

eXist-db, the project behind this site, is an example of a document-oriented, native XML database. Its own materials describe it as "a high-performance native XML database engine and all-in-one solution for building applications," and it is used for exactly the kind of variable-structure content that fits the document model: the U.S. Department of State's Office of the Historian uses it to let visitors "search and browse instantly through nearly a hundred thousand archival government documents," and the Tibetan Buddhist Resource Center describes a collection of "nearly 10 million scanned pages and over 11,000 Unicode Tibetan texts." Those are content-heavy, document-shaped workloads rather than ledger-style transactions.

How NoSQL differs from relational databases

The differences that matter in practice come down to four dimensions:

  • Schema. Relational tables require a defined structure up front; changing it means migrations. Document and key-value stores usually let each record carry its own fields, which suits heterogeneous content but pushes validation into the application.
  • Scaling. Relational systems typically scale up (bigger server) or rely on read replicas; many NoSQL systems are designed to scale out by partitioning data across nodes. That helps with write volume but adds operational work.
  • Consistency. Relational databases generally give you strong, immediate consistency and multi-record transactions. Some NoSQL systems trade this for availability and partition tolerance, meaning reads can be eventually consistent. Check the specific product rather than assuming.
  • Query language. SQL is standardized and join-friendly. NoSQL query interfaces vary widely—XQuery in eXist-db, JSON-style queries in document stores, traversal languages in graph databases—so skills and tooling do not transfer cleanly.

Matching a use case to a type

Use the following as a starting filter:

  • Content and catalogs with uneven fields → document store. If your content is already XML (TEI, DocBook, archival metadata), a native XML database keeps the structure queryable instead of flattening it into columns.
  • Fast single-key access → key-value store.
  • Very high write throughput on semi-structured events → wide-column store.
  • Questions that are really about relationships ("what links to what") → graph database.

For example, a digital humanities project with manuscript metadata, full texts, and cross-references is a document problem first and a graph problem second; a session store for a web app is a key-value problem and nothing more.

Trade-offs and pitfalls

  • Joins get weaker. Cross-record relationships often move into application code or require denormalization, which can drift out of sync.
  • Eventual consistency surprises. If a feature reads immediately after a write, confirm the product's consistency behavior before designing around it.
  • Operational complexity. Distributed NoSQL systems need monitoring, backup, and partitioning decisions that a single relational server does not.
  • Schema flexibility is not free. Without a schema, bad data enters silently; plan validation at the application or database layer.
  • Licensing and cost. eXist-db states it is Open Source Software licensed under the LGPL; do not assume the same for other NoSQL products—verify each one.

A practical way to decide

Write down your three most important queries and your data's variability. If the queries are multi-table joins over stable fields, a relational database is the safer default. If the data is document-shaped and the queries are search-and-retrieve, start with a document store and confirm its query language covers your needs. If the queries are about connections, look at graph. Then prototype the hardest query first—that single test will tell you more than any feature comparison.