Skip to content
AyoKoding

Overview

Prerequisites

  • Prior topics: SQL Essentials and Just Enough Python. See the topic-level Overview for the full statement, including why Advanced SQL & Query Performance is a sharpening companion rather than a hard gate.
  • Tools & environment: a macOS/Linux terminal; Python 3.13; Docker for Valkey/Redis, MongoDB, Cassandra, TimescaleDB, and ClickHouse; the official amazon/dynamodb-local image for DynamoDB; DuckDB runs in-process.
  • Assumed knowledge: relational CRUD and schema design; running a local Docker service; basic Python driver use.

Why this exists -- the big idea

The problem before the solution: forcing every workload through one normalized relational store with strong consistency costs latency and blocks horizontal scale for access patterns that never needed either. Keep-this-if-you-forget-everything: choose the store by the access pattern and the consistency you can actually tolerate.

Confirm your toolchain

Every code-bearing worked example in this topic is a complete, self-contained, fully type-annotated Python file (pyright --strict-clean, DD-39) or a documented CLI transcript (redis-cli, cqlsh, clickhouse-client) colocated under learning/code/. Every example runs against either a real local Docker instance of the store it demonstrates, or -- for the pure-Python conceptual and simulation examples (hashing, replication, LSM-tree, CRDTs, and the like) -- against no external service at all, runnable anywhere Python 3.13 is installed. The three license-check examples (25-27) are the one deliberate exception to "local or no service": each makes a live outbound HTTPS request to fetch a vendor's official license file from GitHub, since a license check is inherently about consulting an external authoritative source.

$ python3 --version
Python 3.13.12
$ python3 -m pip install -r learning/code/requirements.txt
$ docker --version
Docker version 27.x

Start the services -- each store below needs a running container before its examples will connect. Two of the five need a flag beyond a bare docker run, and both are load-bearing, not optional:

  • MongoDB needs a single-node replica set, not a standalone mongod -- multi-document transactions (Examples 34, 35, 72) require one; a standalone mongod rejects start_transaction() outright. Pinning host to localhost:27017 in the rs.initiate call below avoids a real failure mode: leaving host unset makes MongoDB advertise the container's own internal hostname (e.g. c1c9721fc6f8:27017) instead, which the driver then cannot resolve from the host machine, so it isn't enough to run rs.initiate() with no arguments.
  • TimescaleDB is published on 5433, not the image's default 5432 -- every connection string in this topic's TimescaleDB examples already targets 5433, chosen so it does not collide with a Postgres a reader may already have running locally on 5432.
# Valkey/Redis
docker run -d --name nosqldb-redis -p 6379:6379 valkey/valkey:8
 
# MongoDB -- single-node replica set, with the advertised host pinned to localhost
docker run -d --name nosqldb-mongo -p 27017:27017 mongo:8.2 --replSet rs0
docker exec nosqldb-mongo mongosh --quiet --eval \
  'rs.initiate({_id: "rs0", members: [{_id: 0, host: "localhost:27017"}]})'
 
# Cassandra (CQL takes a few seconds to come up after the container starts; retry on refusal)
docker run -d --name nosqldb-cassandra -p 9042:9042 cassandra:5.0
 
# TimescaleDB -- published on 5433, matching every connect string in this topic
docker run -d --name nosqldb-timescale -p 5433:5432 \
  -e POSTGRES_PASSWORD=nosqldb -e POSTGRES_DB=nosqldb \
  timescale/timescaledb:2.28.3-pg16
 
# ClickHouse -- examples discover the running container by image name, so --name is optional
docker run -d clickhouse/clickhouse-server:latest
 
# DynamoDB (local) -- examples connect to the default port 8000
docker run -d -p 8000:8000 amazon/dynamodb-local

Verified end-to-end 2026-07-27 against fresh containers started from exactly these commands: Examples 34, 35, and 72 (the MongoDB multi-document-transaction examples) and Examples 81-85 (the TimescaleDB examples) all connect and print their documented output with no further setup; Example 87 additionally reuses the same TimescaleDB container as a plain Postgres row store (Example 86 needs no container at all -- it runs entirely in-process).

Every printed output block on this topic's pages is a plausible, internally consistent representative transcript, not a literal capture from a live multi-service Docker stack running inside this authoring environment -- the honest framing this topic's by-example convention requires whenever code depends on an external service this environment cannot run. Pure-Python examples with no external dependency (the majority of the conceptual and simulation examples) are genuinely deterministic and reproducible exactly as shown.

Driver/toolchain pins (learning/code/requirements.txt), re-verified 2026-07-27 against the topic's own accuracy-notes sweep -- see the Overview page for the license and version corrections this sweep produced:

redis==8.0.1
pymongo==4.17.0
cassandra-driver==3.30.1
boto3==1.43.56
psycopg[binary]==3.3.4
duckdb==1.5.5
pyarrow==25.0.0

redis and cassandra-driver were independently re-verified by the 2026-07-27 accuracy-notes sweep (see the Overview page); pymongo, boto3, psycopg, duckdb, and pyarrow were confirmed directly by installing each one into this topic's own worked-example environment while authoring the examples below -- every pin above reflects a real resolved version, not a guess.

How this topic's examples are organized

  • Beginner (Examples 1-27) -- Redis/Valkey key-value structures (strings, hashes, lists, sets, sorted sets), TTL and cache-vs-store, MongoDB's document model and a first index, and the conceptual foundations: the NoSQL family taxonomy, when to reach for NoSQL, CAP, PACELC, BASE vs. ACID, eventual consistency, partitioning, consistent hashing, leader-follower replication, access-pattern-first modeling, and the first three license checks.
  • Intermediate (Examples 28-54) -- Redis transactions and optimistic locking, MongoDB's aggregation pipeline and multi-document transactions plus compound and covered indexes, quorum math, Cassandra's quorum tuning, leaderless replication, the three conflict- resolution strategies (LWW, vector clocks, CRDTs), Cassandra's partition/clustering key model, and DynamoDB's item model, single-table design, and GSIs.
  • Advanced (Examples 55-80) -- LSM-tree mechanics and amplification measured directly, Cassandra lightweight transactions, polyglot persistence, denormalization and access-pattern tradeoffs measured on both sides, Redis durability tuning, MongoDB write/read concern, a written CAP/PACELC rationale, DynamoDB conditional writes and hot-partition diagnosis, cross-store tradeoff contrasts, and four capstone-preview examples.
  • Time-series (Examples 81-85) -- TimescaleDB hypertables, time_bucket() downsampling, retention policies, continuous aggregates, and a contrast against the wide-column approach to the same problem.
  • OLAP & columnar analytics (Examples 86-91) -- DuckDB's columnar scan, a measured row-vs-column contrast, Parquet projection, Arrow zero-copy interchange, ClickHouse's MergeTree engine, and a closing wide-column-vs-columnar contrast that makes co-36 concrete.
  • Capstone -- one domain modeled across three NoSQL families (Valkey key-value, MongoDB document, Cassandra wide-column), closing with a written per-store CAP/PACELC and license rationale.

Examples by Level

Beginner (Examples 1-27)

Intermediate (Examples 28-54)

Advanced (Examples 55-80)

Time-series (Examples 81-85)

OLAP & columnar analytics (Examples 86-91)

← Previous: Overview · Next: Beginner Examples →

Last updated July 26, 2026

Command Palette

Search for a command to run...