# Guarantees of YCQL counters

**URL:** <https://forum.yugabyte.com/t/guarantees-of-ycql-counters/287>\
**Category:** General\
**Created:** [March 22, 2019, 7:03pm UTC](https://forum.yugabyte.com/t/guarantees-of-ycql-counters/287 "2019-03-22T19:03:09Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Noorain\_Panjwani](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/noorain_panjwani/32/74_2.png) [@Noorain\_Panjwani](https://forum.yugabyte.com/u/Noorain_Panjwani)\
**Post date:** [March 22, 2019, 7:03pm UTC](https://forum.yugabyte.com/t/guarantees-of-ycql-counters/287/1 "2019-03-22T19:03:09Z")

</div>

Hey. So Cassandra doesn’t have super strong guarantees when it comes to counters (single update could potentially be executed twice in case of slowdowns). What are the guarantees YB has to offer? For counters i mean?

---

<div class="post-metadata">

**Author:** ![kannan](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/kannan/32/18_2.png) [@kannan](https://forum.yugabyte.com/u/kannan)\
**Post date:** [March 24, 2019, 2:27am UTC](https://forum.yugabyte.com/t/guarantees-of-ycql-counters/287/2 "2019-03-24T02:27:54Z")

</div>

YugaByte DB protects against internal retries of the same statement (potentially a non-idempotent statement like a counter column increment) by detecting duplicate writes which may have already succeeded.

In fact, this [was indeed an issue earlier](https://github.com/YugaByte/yugabyte-db/issues/537), but we fixed it (in 2018) as part of our DIY Jepsen testing efforts.

Note: If at the client-driver level you have turned retries on (which is the default) then, yes, you can have a double increment. To avoid that, retries must be turned off at the client-driver level as well.

---

<div class="post-metadata">

**Author:** ![Noorain\_Panjwani](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/noorain_panjwani/32/74_2.png) [@Noorain\_Panjwani](https://forum.yugabyte.com/u/Noorain_Panjwani)\
**Post date:** [March 24, 2019, 2:53am UTC](https://forum.yugabyte.com/t/guarantees-of-ycql-counters/287/3 "2019-03-24T02:53:16Z")

</div>

Makes sense. So the recommended setting for the client driver is to turn off automatic retries?

---

<div class="post-metadata">

**Author:** ![kannan](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/kannan/32/18_2.png) [@kannan](https://forum.yugabyte.com/u/kannan)\
**Post date:** [March 24, 2019, 6:54pm UTC](https://forum.yugabyte.com/t/guarantees-of-ycql-counters/287/4 "2019-03-24T18:54:48Z")

</div>

Retries are nice for idempotent operations. Maybe you can decide based on that.

Another operation is to use CAS (compare-and-swap) - like `SET x = 10 WHERE key = 'k' and x = 9;`

---

<div class="post-metadata">

**Author:** ![Noorain\_Panjwani](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/noorain_panjwani/32/74_2.png) [@Noorain\_Panjwani](https://forum.yugabyte.com/u/Noorain_Panjwani)\
**Post date:** [March 25, 2019, 2:32am UTC](https://forum.yugabyte.com/t/guarantees-of-ycql-counters/287/5 "2019-03-25T02:32:00Z")

</div>

Would there be any performance penalties for using CAS type queries?

---

<div class="post-metadata">

**Author:** ![karthik](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/karthik/32/13_2.png) [@karthik](https://forum.yugabyte.com/u/karthik)\
**Post date:** [March 27, 2019, 4:50am UTC](https://forum.yugabyte.com/t/guarantees-of-ycql-counters/287/6 "2019-03-27T04:50:12Z")

</div>

YugaByte DB implements CAS operations in one roundtrip, compared to 4 for Apache Cassandra, so much more efficient here.

So CAS will be slightly slower than non-CAS operations but not by too much. CAS operations will have to read the value (local read on the leader) before writing while non-CAS operations can simply write (update semantics).