# Using read version for ordering & performance

**URL:** <https://forums.foundationdb.org/t/using-read-version-for-ordering-performance/4345>\
**Category:** Using FoundationDB\
**Created:** [February 1, 2024, 11:39am UTC](https://forums.foundationdb.org/t/using-read-version-for-ordering-performance/4345 "2024-02-01T11:39:10Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![mping-exo](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/mping-exo/32/1374_2.png) [@mping-exo](https://forums.foundationdb.org/u/mping-exo)\
**Post date:** [February 1, 2024, 11:39am UTC](https://forums.foundationdb.org/t/using-read-version-for-ordering-performance/4345/1 "2024-02-01T11:39:11Z")

</div>

I have read some discussions in the forum about using read version as versionstamp, but to my understanding there was not a conclusive answer to this, one of the reasons being when fdb is being restored, the read version can go back.

The app my team is writing has some unique properties:

- every write will be _generated_ by a singleton process (may be processed into fdb downstream by a multiple of processes though), it essentially generates a “write request”
- if we ever do fdb restore, we can afford to stop every writer to FDB while restore is happening

The idea I want to explore is

- return the committed version with every write
- on our main, singleton process, cache the highest version number we’ve seen and make sure any read we generate will use this as read version

This would allow us to:

- ensure we don’t suffer from “lost write” resurfacing (we had this issue where a write was “stuck” due to tls misconfiguration, then it was applied 1h later and overwrote more recent data)
- skip the get-read-version step, thus minimizing latency

Appreciate your comments

---

<div class="post-metadata">

**Author:** ![jzhou](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/jzhou/32/445_2.png) [@jzhou](https://forums.foundationdb.org/u/jzhou)\
**Post date:** [February 3, 2024, 1:38am UTC](https://forums.foundationdb.org/t/using-read-version-for-ordering-performance/4345/2 "2024-02-03T01:38:49Z")

</div>

I think what you said makes sense. Just one more point: after you do a fdb restore, you can use `advanceversion` command of `fdbcli` to make sure the restored cluster has advanced versions to the latest version of the original cluster.