Skip to main content

Glossary

NoSQL

Meaning and details

NoSQL is the umbrella for databases that are not relational tables with SQL: documents (MongoDB, Firestore), key-value (Redis, DynamoDB), wide-column (Cassandra), graph (Neo4j) and search engines (Elasticsearch). The nam...

NoSQL meaning

A family of databases that trade relational strictness for flexible schemas or specialized access patterns: document, key-value, wide-column, graph.

What is NoSQL?

NoSQL is the umbrella for databases that are not relational tables with SQL: documents (MongoDB, Firestore), key-value (Redis, DynamoDB), wide-column (Cassandra), graph (Neo4j) and search engines (Elasticsearch). The name, originally no SQL, softened to not only SQL, and the honest framing is not a rebellion but a menu: each family optimizes a specific access pattern and trades away something relational databases guarantee, usually joins, transactions across documents or ad-hoc queries.

Why it matters to an indie builder: the practical question is never SQL versus NoSQL, it is which access pattern your product actually has. Redis for ephemeral state, queues, caches and rate counters is a default component of almost every stack and worth knowing cold. A document store fits content with nested shapes and ragged fields. Relational Postgres with JSONB columns covers an enormous middle ground, half-structured data with the safety net, and the modern default for indie products is Postgres first, specialized stores second, when a measured need appears.

A concrete example: a session store. In Postgres: every request updates a row, vacuum pressure grows, session cleanup becomes a cron job, and a traffic spike turns into lock contention. In Redis: sessions are keys with a TTL, expiry is automatic, reads land in sub-millisecond time, and a million sessions cost a few hundred megabytes of RAM. One Redis instance beside the main database, and the main database stops caring about your traffic's heartbeat. That is the pattern doing what its family was designed for.

Common mistakes: choosing NoSQL to skip schema design, the schema moves into the code and comes back with interest as validation debt, using a document store for deeply relational data and emulating joins by hand, the classic self-inflicted wound, ignoring consistency guarantees that relational databases give silently (a counter incremented without a transaction is a counter that lies), and running a distributed store single-node for a workload Postgres would have served with backups and zero operations. The hosting and vector-db categories on IndieBoot hold the specialized end of this map.

Keep exploring the glossary