NoSQL
AI apps handle diverse data — JSON docs, session caches, and high-dimensional embeddings. NoSQL optimizes for these patterns.
SQL is a strict filing cabinet. NoSQL is a warehouse with different zones — documents, caches, and vector racks.
Visual Workflows
Start here — study each diagram, then use + / − to zoom if needed.
Overview
Scroll inside the frame · use + / − to zoom
Scroll inside the frame · use + / − to zoom
Key Takeaways
- 1.NoSQL databases handle flexible, non-tabular data — caches, documents, and vector stores power AI architectures.
- 2.Redis for fast caching, MongoDB for flexible documents, vector DBs (Pinecone, ChromaDB) for embedding search.
- 3.Pick the right store per data type.
Real Example
Scenario
Users keep asking the same questions and you're paying for duplicate LLM API calls.
What you would do
Cache responses in Redis with a 1-hour TTL. Cache hit = instant answer, no API cost. Miss = call LLM and store result.
Practice Task
If Redis is installed: run redis-cli SET greeting "hello" then redis-cli GET greeting. If not, write down which database you would use for: user accounts, LLM response cache, and embedding search.
Commands
Commands to Remember
redis-cli # open the Redis command-line interfaceredis-cli GET key # read a cached value by keyredis-cli SET key value EX 3600 # store a value with 1-hour expirymongosh # open the MongoDB shell
Cheat Sheet
Quick recap
quick ref- •Redis — fast key-value cache with TTL for LLM responses
- •MongoDB — flexible JSON document storage
- •Vector DBs (Pinecone, ChromaDB) — embedding similarity search
- •SQL for structured data · NoSQL for flexible / cached / vector data
- •Cache key = hash of input · TTL prevents stale answers
- •Pick the right database per data type — don't use one for everything
Common Mistakes
- ✕One database for everything
- ✕No cache invalidation — stale answers
- ✕Ignoring Redis memory limits