ACID vs BASE Properties
Comparison of ACID (traditional RDBMS) and BASE (NoSQL) consistency models.
Comparison of ACID (traditional RDBMS) and BASE (NoSQL) consistency models.
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.
| Property | Model | Description | Tradeoff |
|---|---|---|---|
| Atomicity | ACID | All or nothing: a transaction completes entirely or not at all. | Requires coordination; adds latency. |
| Consistency | ACID | Database moves from one valid state to another. | Strict consistency may reduce availability. |
| Isolation | ACID | Concurrent transactions do not interfere with each other. | Higher isolation levels reduce concurrency. |
| Durability | ACID | Committed transactions survive system failures. | Needs synchronous write to disk or WAL. |
| Basically Available | BASE | System guarantees availability despite partial failures. | May return stale data during partitions. |
| Soft State | BASE | State may change over time even without new input. | Data consistency is eventual. |
| Eventual Consistency | BASE | Given enough time without new updates, all replicas converge. | Reads may not reflect the latest write. |
| Read Committed | ACID (isolation level) | A transaction sees only data committed before each statement, preventing dirty reads. | Allows non-repeatable reads and phantoms. |
| Repeatable Read | ACID (isolation level) | Rows read once return the same values for the rest of the transaction. | May still allow phantom rows depending on the implementation. |
| Serializable | ACID (isolation level) | The strictest level: the result is as if transactions ran one after another. | Lower concurrency and more aborts or blocking. |
| Snapshot Isolation | ACID (isolation level) | Each transaction works from a consistent snapshot taken at its start. | Permits write skew anomalies unless extra checks are added. |
| Linearizability | Consistency model | Every operation appears to take effect instantly at some point between its start and finish, in a single global order. | Costs latency and availability across replicas. |
| Causal Consistency | Consistency model | Operations that are causally related are seen in the same order by everyone. | Unrelated operations may be seen in different orders. |
| Read-Your-Writes | Consistency model | A client always sees its own previous writes. | Needs sticky sessions or version tracking. |
The shape of this dataset, read from the data itself: every column, its type and a real value. Agents can use this to plan a query without fetching the whole document.
| Section | Field | Type | Example |
|---|---|---|---|
| data | property | string | Atomicity |
| data | model | string | ACID |
| data | description | string | All or nothing: a transaction completes entirel… |
| data | tradeoff | string | Requires coordination; adds latency. |
The static files contain the same reference rows as the API, with no API rate limit. Live metadata, such as view counts, may differ. Use the API for content negotiation; use the static files for a cacheable snapshot.
curl "https://yjtoon.yunusemrevurgun.com/api/dataset/acid-vs-base?format=toon"
const res = await fetch( "https://yjtoon.yunusemrevurgun.com/static-data/dataset/acid-vs-base.toon" ); const toon = await res.text();
Rate limit: 120 requests per minute per IP, no key and no signup. API reference →