Atomicity, Durability, and Consistency

CrateDB employs eventual consistency, which ensures that your database remains highly available and resilient, even in the face of potential network or hardware issues.

For search operations, CrateDB adopts an eventual consistency model rooted in the concept of shared IndexReaders, which provide caching and reverse lookup capabilities for shards. An IndexReader is bound to the Lucene segment it originated from and requires periodic refreshes to reflect new changes. This refresh can occur either in a time-based manner, configurable by the user, or manually triggered using the REFRESH TABLE command. Therefore, a search operation only recognizes a change if the corresponding IndexReader was refreshed after the change occurred.

In contrast, strong consistency is ensured for operations by the primary key when the shard routing key and row identifier can be computed from query specification, such as when the full primary key is defined in the WHERE clause. This approach, accessing a document through a single shard and a straightforward index lookup on the '_id' field, proves to be the most efficient method.

While being an eventually consistent database by default, CrateDB enforces atomicity, durability, and consistency concepts, providing atomic operations at the row level. This means that each write operation on a document either fully succeeds or has absolutely no effect, regardless of the document's complexity or size. This characteristic ensures that the integrity of the database is maintained, even amidst high-volume concurrent reads and writes. This is further complemented by the integration of the Multi Version Concurrency Control (MVCC) system, which equips CrateDB with the capability to handle high data volumes effectively.