api: YAML JSON TOON Database
version: 1.0.0
format: json
dataset:
  slug: acid-vs-base
  title: ACID vs BASE Properties
  description: Comparison of ACID (traditional RDBMS) and BASE (NoSQL) consistency models.
  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.
  use_when:
    - You are explaining what a database guarantees and what it gives up.
    - You need the names of isolation levels and consistency models for a design review.
  caveats:
    - Vendors use 'ACID' and 'strongly consistent' loosely, and isolation level defaults differ between databases.
    - ACID and BASE are poles on a spectrum, not two exclusive categories.
  related:
    - cap-theorem
    - database-comparison
    - nosql-databases-overview
    - newsql-distributed-sql
  category: Database Types
  category_slug: database-types
  tags: database,acid,base,consistency,cap
  view_count: 0
  entry_count: 14
  fields:
    - section: data
      field: property
      type: string
      example: Atomicity
    - section: data
      field: model
      type: string
      example: ACID
    - section: data
      field: description
      type: string
      example: "All or nothing: a transaction completes entirel…"
    - section: data
      field: tradeoff
      type: string
      example: Requires coordination; adds latency.
data:
  - property: Atomicity
    model: ACID
    description: "All or nothing: a transaction completes entirely or not at all."
    tradeoff: Requires coordination; adds latency.
  - property: Consistency
    model: ACID
    description: Database moves from one valid state to another.
    tradeoff: Strict consistency may reduce availability.
  - property: Isolation
    model: ACID
    description: Concurrent transactions do not interfere with each other.
    tradeoff: Higher isolation levels reduce concurrency.
  - property: Durability
    model: ACID
    description: Committed transactions survive system failures.
    tradeoff: Needs synchronous write to disk or WAL.
  - property: Basically Available
    model: BASE
    description: System guarantees availability despite partial failures.
    tradeoff: May return stale data during partitions.
  - property: Soft State
    model: BASE
    description: State may change over time even without new input.
    tradeoff: Data consistency is eventual.
  - property: Eventual Consistency
    model: BASE
    description: Given enough time without new updates, all replicas converge.
    tradeoff: Reads may not reflect the latest write.
  - property: Read Committed
    model: ACID (isolation level)
    description: A transaction sees only data committed before each statement, preventing dirty reads.
    tradeoff: Allows non-repeatable reads and phantoms.
  - property: Repeatable Read
    model: ACID (isolation level)
    description: Rows read once return the same values for the rest of the transaction.
    tradeoff: May still allow phantom rows depending on the implementation.
  - property: Serializable
    model: ACID (isolation level)
    description: "The strictest level: the result is as if transactions ran one after another."
    tradeoff: Lower concurrency and more aborts or blocking.
  - property: Snapshot Isolation
    model: ACID (isolation level)
    description: Each transaction works from a consistent snapshot taken at its start.
    tradeoff: Permits write skew anomalies unless extra checks are added.
  - property: Linearizability
    model: Consistency model
    description: Every operation appears to take effect instantly at some point between its start and finish, in a single global order.
    tradeoff: Costs latency and availability across replicas.
  - property: Causal Consistency
    model: Consistency model
    description: Operations that are causally related are seen in the same order by everyone.
    tradeoff: Unrelated operations may be seen in different orders.
  - property: Read-Your-Writes
    model: Consistency model
    description: A client always sees its own previous writes.
    tradeoff: Needs sticky sessions or version tracking.