Concept: Rust database access via Python database connection pool (via runInteraction) (LLM splat v1)

[MadLittleMods]

Note: This iteration isn't meant to be merged at all and is just meant to see if it's possible. Just splatting this here for the reference. It does seem to work (see testing strategy) although I haven't inspected the code. I just asked an LLM to take my previous non-working structure and make it work.

---

Rust database access via Python database connection pool.

This is a stepping stone before we can go full Rust everywhere. We're providing a generic interface as we want database access to work in Synapse and synapse-rust-apps. In synapse-rust-apps, we will use a tokio-postgres based database connection pool so it's full Rust.

We want to avoid the situation where we have two database connection pools (one for Python, one for Rust) as we've run into connection exhaustion problems on Matrix.org before.

Why runInteraction(...)?

This is a variation of #19824 instead using the runInteraction(...) pattern we already have in Synapse. This means everything that uses the transaction happens in the function callback which enables retries for serialization/deadlock errors when using repeatable-read isolation.

Using the same runInteraction pattern also means we can port over existing Synapse code/endpoints without much thought.

This strategy is less of an impedance mismatch (aligns more closely) with Synapse so the glue code should also be simpler.

Testing strategy

1. poetry run synapse_homeserver --config-path homeserver.yaml
2. GET http://localhost:8008/_matrix/client/versions

Dev notes

LLM Prompt

The goal is to achieve Rust database access via the Python database connection pool.

We're providing a generic interface as we want database access to work in Synapse and a separate project synapse-rust-apps. In synapse-rust-apps, we will use a tokio-postgres based database connection pool so it's full Rust. This is what's being prototyped in rust/src/storage/db/rust_db_pool.rs vs the actual implementation we'll keep here in rust/src/storage/db/python_db_pool.rs.

We want to stick with the runInteraction(...) pattern from Synapse as it allows us to retry transactions in a world where we're using repeatable-read isolation level (serialization and deadlock errors).

I'm in the middle of getting it working and most of it is just non-working structure. Please finish the rest.

As an example, we're doing some Rust database access in rust/src/handlers/versions.rs -> rust/src/storage/store.rs

---

Transaction retries were originally introduced into Synapse for deadlocks which makes me question why they're even happening in the first place. How are other people dealing with this kind of problem? (poorly, not a problem, retries like us, etc)

@reivilibre points out that we're more likely to hit retries because of serialization errors which aligns with the Postgres docs (we use the repeatable read isolation level in Synapse):

When an application receives this error message, it should abort the current transaction and retry the whole transaction from the beginning. The second time through, the transaction will see the previously-committed change as part of its initial view of the database, so there is no logical conflict in using the new version of the row as the starting point for the new transaction's update.

Note that only updating transactions might need to be retried; read-only transactions will never have serialization conflicts.
-- https://www.postgresql.org/docs/current/transaction-iso.html#XACT-REPEATABLE-READ

---

Other PR where I dealt with deferred (make_deferred_yieldable) and async in Rust: #18903

Fix MemoryReactor.callWhenRunning not invoking callbacks if already started, twisted/twisted#12514 - this is relevant because we need to start the tokio thread pool for these tests.

---

PyO3 Rust -> Python logging: https://pyo3.rs/main/ecosystem/logging

Todo

• See how LoggingContext (log context) interact
  • Logging
  • Tracing
• See how metrics work

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request includes a changelog file. The entry should:
  • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
  • Use markdown where necessary, mostly for code blocks.
  • End with either a period (.) or an exclamation mark (!).
  • Start with a capital letter.
  • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
• Code style is correct (run the linters)

[MadLittleMods]

From my high-level reading of things, the type erasure stuff here is because we want DatabasePool to by dyn-compatible because we currently store it like this:

pub struct Store {
    pub config: SynapseConfig,
    pub db_pool: Box<dyn DatabasePool>,
}

If we drop that constraint and instead store the DatabasePool like the following, all of erasure complexity can fall away.

pub struct Store<P: DatabasePool> {
    pub config: SynapseConfig,
    pub db_pool: P,
}

I think the answer depends on whether we care about the Store being Synapse specific or if that also should be shared with synapse-rust-apps.

I think the synapse-rust-apps might have its own Store implementation given we already store things that are Synapse specific in it like SynapseConfig. Although that could be refactored to be different 🤔

[MadLittleMods]

Added d9a111b to see what this looks like

[MadLittleMods]

All of this looks suspect. We shouldn't have to callFromThread as runInteraction already handles creating a thread to work from.

[MadLittleMods]

This should be moved to its own general utility file instead of sharing it this way

[MadLittleMods]

Using futures::executor::block_on(func(&mut txn)); looks fishy but I think it's fine.

The reason func is async is because txn.query(...).await is representing a round-trip between the database which tokio-postgres rightly represents as async and we want to be compatible with that.

Here on the Python-side, txn.query() is backed by blocking Python functions (and the whole transaction gets its own thread to work on). If there is an even simpler/easier way to drive the func here, please shout.

As @reivilibre pointed out in some off the cuff thoughts before any of this kicked off, we just need to document that "'transactions look like async functions but should only call .await on the database' which is a minor cosmetic flaw but seems fine, as you don't want to be doing any unnecessary waiting in your transaction anyway."

[reivilibre]

As a thought, I don't think one should necessarily need an executor for this pattern in Synapse Python at all.

For this reason I am tempted to see what it feels like if we avoided futures::executor::block_on as a first pass and instead manually polled the Future a single time.
Because in Synapse Python we would have no genuine async in this path, it should immediately resolve to Poll::Ready.
Getting Poll::Pending would be considered a programming error.

block_on probably looks 'cleaner' in terms of syntax, but a single-shot poll is more enforcing of the concept we want to represent (and so gets my vote at a first pass).

[erikjohnston]

FWIW I think you can replace String with a custom type:

pub enum DbValue {
   String(String), Bytes(Vec<u8>), Int(i64), Bool(bool), Null,
}

which should be easily convertible on the Python boundary, and when talking to a Rust DB pool

[erikjohnston]

You could probably relax this to a FnMut?

[MadLittleMods]

As an update, twisted/twisted#12514 is finally part of a Twisted release 26.4.0 (2026-05-11). If we updated our Twisted version, we could probably get rid of all of this ugliness.

But that may be a few years away given our deprecation policy considers a "no-brainer" upgrade once it's available in both the latest Debian Stable (currently Twisted 24.11.0) and Ubuntu LTS repositories (currently Twisted 25.5.0)