# What's better about read-only transactions?

**URL:** <https://forums.foundationdb.org/t/whats-better-about-read-only-transactions/1721>\
**Category:** Using FoundationDB\
**Tags:** performance\
**Created:** [November 8, 2019, 4:39am UTC](https://forums.foundationdb.org/t/whats-better-about-read-only-transactions/1721 "2019-11-08T04:39:51Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![rbranson](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/rbranson/32/406_2.png) [@rbranson](https://forums.foundationdb.org/u/rbranson)\
**Post date:** [November 8, 2019, 4:39am UTC](https://forums.foundationdb.org/t/whats-better-about-read-only-transactions/1721/1 "2019-11-08T04:39:51Z")

</div>

Read-only transactions: What’s their purpose short of preventing unintentional writes? I’ve done a bunch of digging and the only thing I can come up with is that it doesn’t require the client to track conflict ranges. Otherwise the read part of a read-write transaction seems to do the same amount of work as a read-only transaction: GRV, and then read from the storage servers.

---

<div class="post-metadata">

**Author:** ![KrzysFR](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/krzysfr/32/43_2.png) [@KrzysFR](https://forums.foundationdb.org/u/KrzysFR)\
**Post date:** [November 8, 2019, 6:00am UTC](https://forums.foundationdb.org/t/whats-better-about-read-only-transactions/1721/2 "2019-11-08T06:00:30Z")

</div>

At the API layer it is also useful to explicitly document in the signature that a method may write and cause conflicts, or is read only and should probably not create conflicts (if nobody else writes)

Attempting to call a method that wants a writable transaction from code that is accepting a readonly transaction is a sign that something got mixed up somewhere.