{ "api": "YAML JSON TOON Database", "version": "1.0.0", "format": "json", "category": { "id": 9, "slug": "database-types", "name": "Database Types", "description": "Different database systems and their characteristics.", "icon": "hard-drive", "created_at": 1783090350, "topic": { "overview": "Database reference data compares the families of data stores and the guarantees behind them: relational systems and the SQL that queries them, ACID transactions versus BASE-style eventual consistency, what the CAP theorem does and does not say about distributed systems, and the NoSQL, graph, time-series and NewSQL systems that trade some properties for others. The consistent theme is trade-offs: no system gives every property at once, so the entries emphasize what each design optimizes for rather than which is best.", "key_ideas": [ { "term": "ACID", "meaning": "Atomicity, consistency, isolation and durability: the guarantees of a classic transaction. A transaction either fully happens or not at all, and committed data survives a crash." }, { "term": "BASE", "meaning": "Basically available, soft state, eventually consistent: a design stance that favors availability and scale over immediate consistency." }, { "term": "CAP theorem", "meaning": "When a network partition occurs, a distributed system must choose between consistency and availability. It does not describe behavior when there is no partition." }, { "term": "Isolation level", "meaning": "How much concurrent transactions can see of one another's work, from read uncommitted to serializable, each preventing a different set of anomalies." }, { "term": "Normalization", "meaning": "Structuring relational tables to reduce redundancy; denormalization deliberately reintroduces it for read speed." }, { "term": "Index", "meaning": "A data structure that speeds up lookups at the cost of storage and slower writes." }, { "term": "Sharding", "meaning": "Splitting data across nodes by key so storage and load scale horizontally." } ], "pitfalls": [ "Reading CAP as 'pick two of three' in normal operation. Partitions are rare; the practical trade-off is often latency versus consistency (PACELC).", "Choosing NoSQL for scale a relational database would handle comfortably, then rebuilding joins and transactions in application code.", "Assuming 'eventually consistent' means 'wrong'. It means replicas converge; applications must tolerate the window.", "Comparing products by feature checklists instead of by their consistency model, failure behavior and operational cost." ], "agent_tips": [ "When asked to recommend a database, ask for the access patterns and consistency needs first; the best choice follows from them.", "Distinguish the data model (relational, document, graph) from the guarantees (ACID or eventual) when explaining a system.", "Treat benchmark and market-share claims as dated; point to current sources rather than quoting figures." ], "start_with": [ "database-comparison", "acid-vs-base" ] } }, "datasets": [ { "id": 1, "slug": "acid-vs-base", "title": "ACID vs BASE Properties", "description": "Comparison of ACID (traditional RDBMS) and BASE (NoSQL) consistency models.", "tags": "database,acid,base,consistency,cap", "view_count": 0, "created_at": 1783090350, "entry_count": 14, "summary": "The ACID transaction properties and the BASE properties of eventually consistent systems, side by side with the trade-off each implies. Extra rows cover the four standard isolation levels and common consistency models that distributed databases advertise." }, { "id": 2, "slug": "cap-theorem", "title": "CAP Theorem", "description": "The CAP theorem: a distributed data store can provide only two of three guarantees simultaneously.", "tags": "database,cap,consistency,availability,partition", "view_count": 0, "created_at": 1783090350, "entry_count": 7, "summary": "The CAP theorem's three guarantees (consistency, availability and partition tolerance) and what choosing CP or AP implies, extended with the PACELC refinement that describes the latency-versus-consistency trade-off when there is no partition." }, { "id": 1010, "slug": "database-isolation-anomalies", "title": "Database Isolation and Concurrency Anomalies", "description": "Concurrency anomalies, example interleavings, and mitigation choices with PostgreSQL-specific caveats.", "tags": "database-types,database isolation anomalies,reference,engineering", "view_count": 0, "created_at": 1791799200, "entry_count": 8, "summary": "Concurrency anomalies, example interleavings, and mitigation choices with PostgreSQL-specific caveats. Each row includes a practical application and a failure to check before using it." }, { "id": 3, "slug": "database-comparison", "title": "Database Systems Comparison", "description": "Comparison of database types: Relational, Document, Key-Value, Column-Family, Graph, and Vector databases with examples and best-fit use cases.", "tags": "database,sql,nosql,comparison", "view_count": 0, "created_at": 1783090350, "entry_count": 11, "summary": "The main families of database systems and what each is best for: relational, document, key-value, column-family, graph and vector, extended with time-series, search, distributed SQL, in-memory and multi-model systems. Each row gives the data model and example products." }, { "id": 4, "slug": "graph-databases-comparison", "title": "Graph Databases Comparison", "description": "Property graphs (Neo4j, Amazon Neptune) vs RDF triplestores (Apache Jena). Query languages (Cypher, Gremlin, SPARQL). Use cases: social networks, recommendation engines, knowledge graphs.", "tags": "graph,database,neo4j,cypher,gremlin,sparql,knowledge-graph", "view_count": 0, "created_at": 1783090350, "entry_count": 8, "summary": "A comparison of graph database systems by data model, query language, storage and ideal use cases, including Neo4j, Amazon Neptune, TigerGraph and ArangoDB, with scaling notes that distinguish native graph stores from multi-model engines." }, { "id": 5, "slug": "newsql-distributed-sql", "title": "NewSQL & Distributed SQL Databases", "description": "Modern distributed SQL databases combining ACID with horizontal scaling: CockroachDB, TiDB, YugabyteDB, Google Spanner, Amazon Aurora, Vitess.", "tags": "database,newsql,distributed-sql,cockroachdb,spanner,aurora", "view_count": 0, "created_at": 1783090350, "entry_count": 7, "summary": "NewSQL and distributed SQL systems that keep SQL and transactional guarantees while scaling out, including CockroachDB, TiDB, YugabyteDB, Google Spanner, Amazon Aurora, Vitess and SingleStore, with their architecture, consistency model and typical uses." }, { "id": 6, "slug": "nosql-databases-overview", "title": "NoSQL Databases Overview", "description": "Document (MongoDB, Couchbase), Key-Value (Redis, DynamoDB), Column-Family (Cassandra, HBase), Graph (Neo4j, JanusGraph). CAP theorem, scaling, use cases.", "tags": "nosql,database,mongodb,redis,cassandra,graph,key-value,document", "view_count": 0, "created_at": 1783090350, "entry_count": 11, "summary": "An overview of NoSQL systems by type, data model, consistency, scalability and best uses, with trade-offs and example users. It covers document, key-value, wide-column and graph stores such as MongoDB, Redis, Cassandra, DynamoDB and Neo4j." }, { "id": 1009, "slug": "sql-index-patterns", "title": "PostgreSQL Index Design Patterns", "description": "Index choices for equality, ordered retrieval, selective predicates, and specialized PostgreSQL workloads.", "tags": "database-types,sql index patterns,reference,engineering", "view_count": 0, "created_at": 1791799200, "entry_count": 10, "summary": "Index choices for equality, ordered retrieval, selective predicates, and specialized PostgreSQL workloads. Each row includes a practical application and a failure to check before using it." }, { "id": 7, "slug": "sql-join-types", "title": "SQL Join Types", "description": "Reference for all SQL JOIN types and their use cases.", "tags": "database,sql,joins,reference", "view_count": 0, "created_at": 1783090350, "entry_count": 15, "summary": "The SQL join types with a description and example syntax: inner, left, right, full outer, cross and self joins, plus semi and anti joins, lateral joins and natural joins that appear in real queries." }, { "id": 8, "slug": "sql-query-types", "title": "SQL Query Types Reference", "description": "Categories of SQL statements for data definition, manipulation, and control.", "tags": "sql,database,query,reference", "view_count": 0, "created_at": 1783090350, "entry_count": 5, "summary": "The SQL statement categories: DDL for schema, DML for changing data, DCL for permissions, TCL for transactions and DQL for queries, each with its full name, the statements it contains and its purpose." }, { "id": 1008, "slug": "sql-window-functions", "title": "SQL Window Functions with Examples", "description": "PostgreSQL window functions and explicit frame patterns for ranks, running totals, and neighboring rows.", "tags": "database-types,sql window functions,reference,engineering", "view_count": 0, "created_at": 1791799200, "entry_count": 12, "summary": "PostgreSQL window functions and explicit frame patterns for ranks, running totals, and neighboring rows. Each row includes a practical application and a failure to check before using it." }, { "id": 9, "slug": "time-series-databases", "title": "Time-Series Databases Comparison", "description": "Comparison of time-series databases: InfluxDB, TimescaleDB, Prometheus, VictoriaMetrics, QuestDB, and ClickHouse. Storage engines, query languages, compression, and use cases.", "tags": "time-series,influxdb,timescaledb,prometheus,victoriametrics,questdb,clickhouse,metrics,monitoring", "view_count": 0, "created_at": 1783090350, "entry_count": 6, "summary": "A comparison of time-series databases (InfluxDB, TimescaleDB, Prometheus, VictoriaMetrics, QuestDB and ClickHouse) by storage engine, query language, compression, clustering, strengths, weaknesses and typical use." } ] }