[Atomic Glue](atomicglue.co)
BACKEND
Home › Glossary › Backend· 289 ·

NoSQL

\\noh-ess-kyoo-el\\n.
Filed underBackendSoftware EngineeringAnalytics
In brief · quick answer

NoSQL (Not Only SQL) is a category of database systems that provide flexible, non-tabular data models for specific use cases where relational databases are less optimal. Types include document, key-value, wide-column, and graph databases.

§ 1 Definition

NoSQL databases emerged in the late 2000s to address limitations of relational databases at internet scale. The term 'NoSQL' was coined in 1998 and revived in 2009 for a meetup about distributed, non-relational databases. NoSQL databases trade some of the guarantees of relational databases (ACID transactions, strict schemas) for flexibility, horizontal scalability, or specialized query capabilities. NoSQL is not a single technology. It is four distinct database types optimized for different workloads. Document databases (MongoDB, CouchDB) store JSON-like documents with flexible schemas. Key-value stores (Redis, DynamoDB) are the simplest and fastest, storing opaque values by key. Wide-column stores (Cassandra, HBase) scale massively across many servers. Graph databases (Neo4j, ArangoDB) model relationships explicitly. The common thread is schema flexibility and horizontal scaling. The tradeoff is that NoSQL databases typically sacrifice consistency guarantees (BASE instead of ACID) and query expressiveness. The right choice depends on your specific data model and access patterns, not a blanket preference.

§ 2 Document Databases (MongoDB, CouchDB)

Document databases store data as self-contained documents (typically JSON or BSON). Each document can have different fields, making the schema flexible. Related data is often embedded within a document rather than split across tables with joins. This denormalization matches how application code works with objects and can improve read performance by avoiding joins. The tradeoff is data duplication and the complexity of keeping embedded data consistent. MongoDB is the dominant document database, with a query API that supports filtering, aggregation pipelines, geospatial queries, and indexes (including text and TTL indexes). MongoDB 7.x added multi-document ACID transactions, narrowing the gap with relational databases. Document databases excel at content management, catalogs, and applications with evolving schemas.

§ 3 Key-Value Stores (Redis, DynamoDB)

Key-value stores are the simplest NoSQL type. Data is stored as a value retrievable by a unique key. The value is opaque to the database (it cannot query inside the value). This simplicity enables extreme performance: Redis serves millions of operations per second in memory. DynamoDB scales horizontally with predictable performance at any scale. Key-value stores are best for caching, session storage, user profiles, and feature flags. They are not suitable for complex queries, relationships, or reporting. Redis is also used for real-time features (pub/sub, leaderboards, rate limiting, message queues) due to its rich data structures (strings, hashes, lists, sets, sorted sets, streams). DynamoDB is AWS's managed key-value/document database with automatic scaling and single-digit-millisecond performance at any scale.

§ 4 Wide-Column and Graph Databases

Wide-column stores (Cassandra, HBase, Scylla) store data in tables with rows and columns, but unlike relational databases, each row can have different columns. They are designed for massive scale across many commodity servers with no single point of failure. Cassandra offers tunable consistency (you choose between availability and consistency per operation). It excels at time-series data, IoT sensor data, and applications that need write throughput at petabyte scale. Graph databases (Neo4j, Amazon Neptune) model data as nodes (entities) connected by edges (relationships). Graph queries (Cypher, SPARQL) traverse relationships efficiently, making graph databases ideal for social networks, recommendation engines, fraud detection, and knowledge graphs. If your data model is inherently graph-like (users, products, recommendations), a graph database is dramatically more natural and performant than emulating relationships in SQL.

§ 5 Note

Common misunderstanding: NoSQL databases are not replacements for SQL databases. They are alternatives for specific use cases. Using MongoDB for an accounting system (which needs ACID transactions and strict schema enforcement) would be a mistake. Using PostgreSQL for a real-time leaderboard (which Redis handles effortlessly) would be overcomplicating a simple problem. Another misconception: NoSQL means 'no schema.' Document databases have implicit schemas enforced by application code. A collection of user documents is expected to have a consistent structure regardless of the database enforcing it. MongoDB's schema validation (JSON Schema) lets you enforce schemas at the database level too. Also: 'NoSQL' is a category of databases that share almost nothing beyond 'not relational.' The differences between MongoDB, Redis, Cassandra, and Neo4j are larger than the differences between any one of them and PostgreSQL.

§ 6 In code

```javascript
// MongoDB document model
const userDoc = {
  _id: ObjectId('...'),
  email: '[email protected]',
  profile: {
    name: 'Alice',
    avatar: '/avatars/a1.jpg'
  },
  roles: ['user', 'moderator'],
  preferences: {
    theme: 'dark',
    notifications: { email: true, push: false }
  },
  created_at: ISODate('2026-01-15')
};

// Rich embedded data instead of joins
const orderDoc = {
  _id: ObjectId('...'),
  user: { id: ObjectId('...'), name: 'Alice' },
  items: [
    { sku: 'ABC', qty: 2, price: 19.99 },
    { sku: 'XYZ', qty: 1, price: 39.99 }
  ],
  total: 79.97,
  status: 'shipped'
};
```

§ 7 Common questions

Q. Should I use MongoDB or PostgreSQL for my new app?
A. Start with PostgreSQL. If you find yourself repeatedly embedding data, fighting with joins, or needing to evolve your schema rapidly, evaluate MongoDB. PostgreSQL handles JSON and flexible schemas better than most people realize.
Q. Is NoSQL faster than SQL?
A. For specific use cases, yes. Redis (in-memory key-value) is faster than any SQL database for caching. Cassandra is faster for write-heavy workloads at scale. But for a typical web application with standard CRUD operations, PostgreSQL with proper indexing is competitive with any NoSQL database.
Q. When should I use a graph database?
A. When your data model is inherently graph-like: social networks, recommendation engines, fraud detection, knowledge graphs, and network/infrastructure mapping. If your mental model of the data is 'nodes connected by edges,' use a graph database.
Key takeaways
  • NoSQL is four distinct database types: Document, Key-Value, Wide-Column, and Graph.
  • NoSQL trades relational guarantees for flexibility, scale, or specialized performance.
  • NoSQL is not a replacement for SQL. Choose the right database for each workload (polyglot persistence).
  • PostgreSQL is recommended as the primary database; add NoSQL databases for specific needs.
How Atomic Glue helps

Atomic Glue evaluates and integrates NoSQL databases when your application needs them. We use Redis for caching and real-time features, MongoDB for flexible document storage, and evaluate Cassandra for high-volume write workloads. Our default is PostgreSQL for transactional data, adding specialized databases only when there is a clear performance or data-modeling advantage. Polyglot persistence is part of our data architecture approach within our Web Development services. Get in touch to design your data layer.

Get in touch
# NoSQL

NoSQL (Not Only SQL) is a category of database systems that provide flexible, non-tabular data models for specific use cases where relational databases are less optimal. Types include document, key-value, wide-column, and graph databases.

Category: Backend (also: Software Engineering, Analytics)

Author: Atomic Glue Development Team

## Definition

NoSQL databases emerged in the late 2000s to address limitations of relational databases at internet scale. The term 'NoSQL' was coined in 1998 and revived in 2009 for a meetup about distributed, non-relational databases. NoSQL databases trade some of the guarantees of relational databases (ACID transactions, strict schemas) for flexibility, horizontal scalability, or specialized query capabilities. NoSQL is not a single technology. It is four distinct database types optimized for different workloads. Document databases (MongoDB, CouchDB) store JSON-like documents with flexible schemas. Key-value stores (Redis, DynamoDB) are the simplest and fastest, storing opaque values by key. Wide-column stores (Cassandra, HBase) scale massively across many servers. Graph databases (Neo4j, ArangoDB) model relationships explicitly. The common thread is schema flexibility and horizontal scaling. The tradeoff is that NoSQL databases typically sacrifice consistency guarantees (BASE instead of ACID) and query expressiveness. The right choice depends on your specific data model and access patterns, not a blanket preference.

## Document Databases (MongoDB, CouchDB)

Document databases store data as self-contained documents (typically JSON or BSON). Each document can have different fields, making the schema flexible. Related data is often embedded within a document rather than split across tables with joins. This denormalization matches how application code works with objects and can improve read performance by avoiding joins. The tradeoff is data duplication and the complexity of keeping embedded data consistent. MongoDB is the dominant document database, with a query API that supports filtering, aggregation pipelines, geospatial queries, and indexes (including text and TTL indexes). MongoDB 7.x added multi-document ACID transactions, narrowing the gap with relational databases. Document databases excel at content management, catalogs, and applications with evolving schemas.

## Key-Value Stores (Redis, DynamoDB)

Key-value stores are the simplest NoSQL type. Data is stored as a value retrievable by a unique key. The value is opaque to the database (it cannot query inside the value). This simplicity enables extreme performance: Redis serves millions of operations per second in memory. DynamoDB scales horizontally with predictable performance at any scale. Key-value stores are best for caching, session storage, user profiles, and feature flags. They are not suitable for complex queries, relationships, or reporting. Redis is also used for real-time features (pub/sub, leaderboards, rate limiting, message queues) due to its rich data structures (strings, hashes, lists, sets, sorted sets, streams). DynamoDB is AWS's managed key-value/document database with automatic scaling and single-digit-millisecond performance at any scale.

## Wide-Column and Graph Databases

Wide-column stores (Cassandra, HBase, Scylla) store data in tables with rows and columns, but unlike relational databases, each row can have different columns. They are designed for massive scale across many commodity servers with no single point of failure. Cassandra offers tunable consistency (you choose between availability and consistency per operation). It excels at time-series data, IoT sensor data, and applications that need write throughput at petabyte scale. Graph databases (Neo4j, Amazon Neptune) model data as nodes (entities) connected by edges (relationships). Graph queries (Cypher, SPARQL) traverse relationships efficiently, making graph databases ideal for social networks, recommendation engines, fraud detection, and knowledge graphs. If your data model is inherently graph-like (users, products, recommendations), a graph database is dramatically more natural and performant than emulating relationships in SQL.

## Note

Common misunderstanding: NoSQL databases are not replacements for SQL databases. They are alternatives for specific use cases. Using MongoDB for an accounting system (which needs ACID transactions and strict schema enforcement) would be a mistake. Using PostgreSQL for a real-time leaderboard (which Redis handles effortlessly) would be overcomplicating a simple problem. Another misconception: NoSQL means 'no schema.' Document databases have implicit schemas enforced by application code. A collection of user documents is expected to have a consistent structure regardless of the database enforcing it. MongoDB's schema validation (JSON Schema) lets you enforce schemas at the database level too. Also: 'NoSQL' is a category of databases that share almost nothing beyond 'not relational.' The differences between MongoDB, Redis, Cassandra, and Neo4j are larger than the differences between any one of them and PostgreSQL.

## In code

## Common questions
Q: Should I use MongoDB or PostgreSQL for my new app?
A: Start with PostgreSQL. If you find yourself repeatedly embedding data, fighting with joins, or needing to evolve your schema rapidly, evaluate MongoDB. PostgreSQL handles JSON and flexible schemas better than most people realize.
Q: Is NoSQL faster than SQL?
A: For specific use cases, yes. Redis (in-memory key-value) is faster than any SQL database for caching. Cassandra is faster for write-heavy workloads at scale. But for a typical web application with standard CRUD operations, PostgreSQL with proper indexing is competitive with any NoSQL database.
Q: When should I use a graph database?
A: When your data model is inherently graph-like: social networks, recommendation engines, fraud detection, knowledge graphs, and network/infrastructure mapping. If your mental model of the data is 'nodes connected by edges,' use a graph database.

## Key takeaways

## Related entries


Last updated June 2026. Permalink: atomicglue.co/glossary/nosql

Schedule a call

30 min · Video call

1
Date
2
Time
3
Details