A conditional update changes a database row only when a supplied condition about its current state evaluates to true. In ScyllaDB, lightweight transactions provide this coordination, avoiding a separate application read, decision, and write sequence. section 6.5
This is useful when ordinary writes could overwrite valid data or create a logically incomplete row. Timestamp-based conflict resolution cannot understand intent, so concurrent writes can produce lost updates; conditional updates add an explicit check against the row’s state. section 6.1.2 section 6.5
Use a conditional update when the write depends on information already stored in the target row:
- Check that a row exists before changing it. section 6.5
- Prevent an update from overwriting data changed by another operation. section 6.1.2
- Prefer the database-side condition when an application read followed by a write could race with another user. section 6.5
Protecting an author row
In the restaurant-review application, User A reads an author’s bio while User B deletes that author. Without coordination, User A’s later bio update can recreate a row containing only the ID and bio, leaving out the author’s name. A conditional update can require that the row still exists; if the condition is false, the update does not run. section 6.5
Conditional updates improve coordination but add compute cost. They are one option alongside client-side coordination such as distributed locking, and should be chosen when the state check is worth that additional cost. section 6.4.2 section 6.1.2
