[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-nosql::en":3,"gloss-cluster-nosql::en":20,"gloss-next-nosql::en":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"nosql","data-infra","NoSQL","NoSQL is an umbrella term for database systems that don't use the traditional relational (table-and-row, SQL-queried) model, generally trading some of the strict schema enforcement and join capabilities of relational databases for schema flexibility, easier horizontal scaling, and — depending on the specific system — different performance characteristics for specific access patterns. It splits into several distinct families that get lumped together under one label but behave very differently: document stores (MongoDB, Firestore — store semi-structured JSON-like documents, good fit for nested\u002Fvariable-shape data); key-value stores (Redis, DynamoDB — extremely fast simple lookups by key, minimal query flexibility); wide-column stores (Cassandra, HBase — built for massive write throughput and horizontal scale across many nodes); and graph databases (Neo4j — optimized for traversing relationships, like \"friends of friends,\" efficiently). Why it matters for AI\u002FSaaS builders: NoSQL databases show up in AI products specifically where data genuinely doesn't fit a fixed relational schema well — storing arbitrary, evolving LLM tool-call payloads, flexible per-customer configuration objects, or chat conversation history where message structure varies — or where a specific access pattern (extremely high write throughput, simple key-based lookups at massive scale) outweighs the benefits of joins and strict schema. It's worth noting that vector databases are, technically, a specialized form of NoSQL database, and modern \"multi-model\" databases (MongoDB with vector search, Postgres with `jsonb` and pgvector) have blurred the historical SQL-vs-NoSQL line considerably — a team no longer strictly has to choose one paradigm exclusively. How it works: most NoSQL systems relax one or more of the ACID guarantees relational databases enforce, typically favoring \"eventual consistency\" (a write is guaranteed to propagate to all replicas\u002Fnodes eventually, but not necessarily instantly) in exchange for higher availability and easier horizontal scaling across many commodity servers — a trade-off formalized by the CAP theorem, which states a distributed system can only fully guarantee two of Consistency, Availability, and Partition tolerance at once. Worked example: an AI chatbot SaaS stores conversation transcripts — where message structure varies (some messages are plain text, some contain tool calls, some contain generated images with metadata) — in MongoDB as flexible JSON documents rather than forcing every possible message shape into a rigid set of relational columns, while keeping billing, users, and subscriptions in Postgres where ACID guarantees and structured joins genuinely matter. This kind of deliberate \"polyglot persistence\" — picking a different database technology per data type based on its actual access pattern, rather than forcing every kind of data into one system for the sake of operational simplicity — is increasingly the norm for AI products specifically, since so much AI-adjacent data (chat history, embeddings, tool-call payloads) genuinely doesn't fit the relational model as naturally as a subscription record does.","NoSQL describes non-relational databases — document, key-value, wide-column, or graph stores — built for flexible schemas and horizontal scale.",null,[11,14,17],{"slug":12,"name":13},"acid","ACID",{"slug":15,"name":16},"data-lake","Data Lake",{"slug":18,"name":19},"postgresql","PostgreSQL",[21,23,26,29,32,36,39,42,45,48,52,55],{"slug":12,"category":5,"name":13,"updated_at":22},"2026-08-24T02:46:37+00:00",{"slug":24,"category":5,"name":25,"updated_at":22},"ann-search","ANN Search",{"slug":27,"category":5,"name":28,"updated_at":22},"backpressure","Backpressure",{"slug":30,"category":5,"name":31,"updated_at":22},"batch-processing","Batch Processing",{"slug":33,"category":5,"name":34,"updated_at":35},"bm25","BM25","2026-08-24T02:46:38+00:00",{"slug":37,"category":5,"name":38,"updated_at":22},"cache","Cache",{"slug":40,"category":5,"name":41,"updated_at":22},"cap-theorem","CAP Theorem",{"slug":43,"category":5,"name":44,"updated_at":22},"change-data-capture","Change Data Capture (CDC)",{"slug":46,"category":5,"name":47,"updated_at":22},"chroma","Chroma",{"slug":49,"category":5,"name":50,"updated_at":51},"chunk-overlap","Chunk Overlap","2026-08-24T03:30:02+00:00",{"slug":53,"category":5,"name":54,"updated_at":22},"columnar-storage","Columnar Storage",{"slug":56,"category":5,"name":57,"updated_at":22},"connection-pooling","Connection Pooling"]