# Uniqueness of rows **URL:** \ **Category:** Ask for Help\ **Created:** [February 6, 2024, 6:20am UTC](https://community.glideapps.com/t/uniqueness-of-rows/70544 "2024-02-06T06:20:26Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![Darren\_Murphy](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/darren_murphy/32/47326_2.png) [@Darren\_Murphy](https://community.glideapps.com/u/Darren_Murphy)\ **Post date:** [February 6, 2024, 11:58am UTC](https://community.glideapps.com/t/uniqueness-of-rows/70544/4 "2024-02-06T11:58:08Z")
Yes, you’re right. Because the operations are not atomic, there is always a small chance that collisions can happen and you wind up with duplicates. A while back, David suggested using something like Upstash with Redis to handle this. I’ve not had a need to try it yet, but I’ve been keeping it in the back of my mind should that need arise. > [@new Please Test: Make.com Integration](https://community.glideapps.com/t/please-test-make-com-integration/67979/16): > > Increment is not an atomic operation. The increment happens on the client, and the result is sent to the server. For atomic increment, you should use Call API with a service like Upstash that offers serverless redis (a database with first-class support for atomic increment). You can get a good result this way! We did it for PGA when they needed a distributed counter for their grandstands. We’d like to offer atomic increment in Glide but it’s not a top request from customers yet. --- _[View the full topic](https://community.glideapps.com/t/uniqueness-of-rows/70544)._