Add support for Postgres database #10

New issue

Open

opened 2026-06-15 22:45:14 +00:00 by shadowdrake · 1 comment

shadowdrake commented

2026-06-15 22:45:14 +00:00

Collaborator

Add config toggle to enable writing to Postgres database - useful in deployments from #9 as MDAD provides a managed postgres database already

Need to:

Confirm all SQL queries are compatible with postgres
Add config toggle to enable sqlite or postgres database selection
Add config options for postgres connection path (or sqlite - can reference mautrix-go)

Add config toggle to enable writing to Postgres database - useful in deployments from #9 as MDAD provides a managed postgres database already Need to: - Confirm all SQL queries are compatible with postgres - Add config toggle to enable sqlite or postgres database selection - Add config options for postgres connection path (or sqlite - can reference mautrix-go)

dark added the

enhancement

label

2026-06-16 05:18:08 +00:00

robocub commented

2026-06-23 22:49:55 +00:00

Collaborator

After digging into the storage architecture for this, a heads-up that this is more involved than the issue assumes — and likely not the right tool for this bridge.

This bridge has no SQL of its own. Unlike mautrix bridges (which own a schema and support sqlite/postgres), nether-voicebridge has zero SQL queries, zero sqlx/rusqlite/postgres dependencies, and no tables. All persistence is matrix-sdk's stores (crypto + state + event-cache), which use SQLite internally via the bundled-sqlite feature. So there's nothing of "ours" to make Postgres-compatible — the first task in this issue ("confirm all SQL queries are compatible") doesn't apply.

Supporting Postgres would mean writing a custom Postgres backend for matrix-sdk's stores (implementing its StateStore + CryptoStore + EventCacheStore traits). matrix-sdk 0.18 doesn't ship one (only SQLite + IndexedDB-for-wasm), so we'd own and maintain it ourselves. The CryptoStore half is E2EE-correctness-critical — getting it subtly wrong breaks encrypted audio. Realistically this is weeks of work plus a permanent maintenance/risk burden, not a config toggle.

The practical path for MDAD / managed deploys: this bridge isn't a homeserver — its stores are small, embedded, per-process SQLite files. What it needs for statefulness is a persistent volume for NVB_DATA_DIR, which the Docker image already supports (VOLUME ["/app/data"], store paths auto-derive under it). Postgres is the right choice for Synapse-class services; for a voice participant bridge with tiny local stores, a mounted volume is the correct and far simpler answer. If a deployment genuinely can only offer Postgres and not a volume, the real fix is upstream matrix-sdk gaining a Postgres store — not us reimplementing it.

Recommendation: keep SQLite + a persistent volume; revisit only if matrix-sdk adds first-class Postgres support.

After digging into the storage architecture for this, a heads-up that this is more involved than the issue assumes — and likely not the right tool for this bridge. **This bridge has no SQL of its own.** Unlike mautrix bridges (which own a schema and support sqlite/postgres), nether-voicebridge has zero SQL queries, zero `sqlx`/`rusqlite`/`postgres` dependencies, and no tables. *All* persistence is **matrix-sdk's** stores (crypto + state + event-cache), which use SQLite internally via the `bundled-sqlite` feature. So there's nothing of "ours" to make Postgres-compatible — the first task in this issue ("confirm all SQL queries are compatible") doesn't apply. **Supporting Postgres would mean writing a custom Postgres backend for matrix-sdk's stores** (implementing its `StateStore` + `CryptoStore` + `EventCacheStore` traits). matrix-sdk 0.18 doesn't ship one (only SQLite + IndexedDB-for-wasm), so we'd own and maintain it ourselves. The `CryptoStore` half is E2EE-correctness-critical — getting it subtly wrong breaks encrypted audio. Realistically this is weeks of work plus a permanent maintenance/risk burden, not a config toggle. **The practical path for MDAD / managed deploys:** this bridge isn't a homeserver — its stores are small, embedded, per-process SQLite files. What it needs for statefulness is a **persistent volume** for `NVB_DATA_DIR`, which the Docker image already supports (`VOLUME ["/app/data"]`, store paths auto-derive under it). Postgres is the right choice for Synapse-class services; for a voice *participant* bridge with tiny local stores, a mounted volume is the correct and far simpler answer. If a deployment genuinely can only offer Postgres and not a volume, the real fix is upstream matrix-sdk gaining a Postgres store — not us reimplementing it. Recommendation: keep SQLite + a persistent volume; revisit only if matrix-sdk adds first-class Postgres support.

dark added this to the Roadmap project

2026-06-27 16:29:34 +00:00

robocub referenced this issue

2026-06-27 16:46:54 +00:00

Runtime bridge provisioning (supervisor + tenant persistence) #45

robocub referenced this issue from a commit

2026-07-11 00:49:34 +00:00

test(e2e): DiscordMod actor + external-disconnect/force-move recovery scenarios (#38 D3 batch 2 / B)