# Spiking SQLCipher for Room - Surprising Benchmark Results

**URL:** <https://discuss.zetetic.net/t/spiking-sqlcipher-for-room-surprising-benchmark-results/6961>\
**Category:** SQLCipher\
**Created:** [June 4, 2025, 7:40pm UTC](https://discuss.zetetic.net/t/spiking-sqlcipher-for-room-surprising-benchmark-results/6961 "2025-06-04T19:40:20Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![koji-taller](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.zetetic.net/koji-taller/32/2416_2.png) [@koji-taller](https://discuss.zetetic.net/u/koji-taller)\
**Post date:** [June 4, 2025, 7:40pm UTC](https://discuss.zetetic.net/t/spiking-sqlcipher-for-room-surprising-benchmark-results/6961/1 "2025-06-04T19:40:20Z")

</div>

I’ve been exploring the addition of encryption to our Room database using [SQLCipher for Android](https://github.com/sqlcipher/sqlcipher-android).

During this spike, I expected a performance overhead due to encryption, but surprisingly, I observed **better performance** in both read and write operations when using the encrypted database.

#### Benchmark Setup

To compare performance, I created two singleton Room databases:

- **Encrypted DB** using SQLCipher
- **Unencrypted DB** using standard Room

##### Benchmark Strategy:

- The benchmark ran a loop of **250 iterations**.
- In each iteration, one of the following operations was selected at random:
  - Write to encrypted DB
  - Read from encrypted DB
  - Write to unencrypted DB
  - Read from unencrypted DB

- The operations simulate real-world scenarios like storing and retrieving raw data (e.g., JSON payloads or entities).
- I recorded the execution time of each operation and calculated the **average time** per operation type.

#### Results after 3 runs

| Operation | **Average Time (ms)** |
| --- | --- |
| ENCRYPTED\_WRITE | 7.40 |
| ENCRYPTED\_READ | 179.12 |
| NORMAL\_WRITE | 10.41 |
| NORMAL\_READ | 245.58 |

While the results are promising, they were unexpected. I anticipated encryption would introduce some overhead, not a performance gain. I’m wondering:

- Is this benchmarking approach valid? Is 250 iterations sufficient, and is random operation selection realistic?
- Could there be caching, memory optimizations, or filesystem effects influencing results?
- Is there a known reason why SQLCipher might outperform default SQLite in some scenarios?

---

<div class="post-metadata">

**Author:** ![sjlombardo](https://sea2.discourse-cdn.com/flex016/user_avatar/discuss.zetetic.net/sjlombardo/32/3_2.png) [@sjlombardo](https://discuss.zetetic.net/u/sjlombardo)\
**Post date:** [June 5, 2025, 8:35pm UTC](https://discuss.zetetic.net/t/spiking-sqlcipher-for-room-surprising-benchmark-results/6961/2 "2025-06-05T20:35:27Z")

</div>

Hello @koji-taller, yes, those results do sound unusual. Encryption does add overhead to the process. The amount of overhead can vary from zero to “a lot” depending on the a number of factors. In most of our historical benchmarking the average tends to be around 5% - 15% for our optimized commercial edition packages with a reasonably well designed database, good integration practices, and high quality application database code.

My first instinct is that the sample size is too small, so increase that. There are other factors that could be at play, but I would check that first. Make sure you are testing on like hardware, under similar load, etc.

Outside of that, check for logic issues, e.g. the files are actually encrypted, that the reports aren’t flip-flopped (encrypted being reported as unencrypted), etc.