From an API evolution standpoint, cursors are a no-brainer over explicit offsets: 1. Nothing stops you from having your cursors be implemented via a SQL offset

From an API evolution standpoint, cursors are a no-brainer over explicit offsets: 1. Nothing stops you from having your cursors be implemented via a SQL offset under the hood. 2. You can have your cursors be base64 data, and embed a cursor version in the ID. You can use this to change how your pagination works without breaking clients during the transition period. (You'll need to document+enforce a maximum validity for pagination tokens to do this successfully.) 3. You can encrypt your pagination tokens, so clients don't get used to making assumptions about how your pagination works under the hood. (This isn't security by obscurity, it's just defending against Hyrum's Law [1].) It doesn't cost you much to implement cursors early on, and unlike offsets they will grow with you across the evolution of your API. [1]: https://www.hyrumslaw.com/ https://www.hyrumslaw.com/