Spiking SQLCipher for Room - Surprising Benchmark Results

SQLCipher
1

I’ve been exploring the addition of encryption to our Room database using SQLCipher for 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?
2

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.