feat(sqlite): Replace deadpool-sqlite by our own implementation

[Hywan]

Initially, we were using deadpool-sqlite, that is also using rusqlite as the SQLite interface. However, in the implementation of deadpool::managed::Manager, when recycling an object (i.e. an SQLite connection), an SQL query is run to detect whether the connection is still alive. It creates performance issues:

1. It runs a prepared SQL query, which has a non-negligle cost. Imagine each connection is used to run on average one query; when recycled, a second query was constantly run. Even if it's a simple query, it requires to prepare a statement, to run and to query it.
2. The SQL query was run in a blocking task. Indeed, deadpool_runtime::spawn_blocking is used (via deadpool_sync::SyncWrapper::interact), which includes using a blocking thread (they are limited), acquiring a lock etc. All this has more performance cost.

Measures have shown it is a performance bottleneck for us, especially on Android. Why specifically on Android and not other systems? This is still unclear at the time of writing (2025-11-11), despite having spent several days digging and trying to find an answer to this question (kudos to @jmartinesp who didn't count its hours on this…).

We have tried to use another approach to test the aliveness of the connections without running queries. It has involved patching rusqlite to add more bindings to SQLite, and patching deadpool itself, but without any successful results.

Finally, we have started questioning the reason of this test: why testing whether the connection was still alive? After all, there is no reason a connection should die in our case:

• all connections are local,
• all interactions are behind WAL, which is local only,
• even if for an unknown reason the connection died, using it next time would create an error… exactly what would happen when recycling the connection.

Consequently, we have created a new implementation of deadpool for rusqlite that doesn't test the aliveness of the connections when recycled. We assume they are all alive.

This implementation is, at the time of writing (2025-11-11):

• 3.5 times faster on Android than deadpool-sqlite, removing the lock and thread contention entirely,
• 2 times faster on iOS.

[codecov]

Codecov Report

❌ Patch coverage is 73.80952% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.61%. Comparing base (3b14184) to head (eaec1db).
⚠️ Report is 13 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
crates/matrix-sdk-sqlite/src/crypto_store.rs	0.00%	0 Missing and 4 partials ⚠️
crates/matrix-sdk-sqlite/src/state_store.rs	42.85%	0 Missing and 4 partials ⚠️
crates/matrix-sdk-sqlite/src/connection.rs	84.21%	3 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5841   +/-   ##
=======================================
  Coverage   88.61%   88.61%           
=======================================
  Files         361      362    +1     
  Lines      102269   102292   +23     
  Branches   102269   102292   +23     
=======================================
+ Hits        90627    90648   +21     
- Misses       7420     7422    +2     
  Partials     4222     4222           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

CodSpeed Performance Report

Merging #5841 will not alter performance

_{Comparing Hywan:feat-sqlite-custom-pool-manager (eaec1db) with main (fff270d)}

Summary

✅ 50 untouched

[jmartinesp]

I've been using it for 4 days now with no issues and outstanding performance, so it definitely LGTM!