element-hq / element-hq/synapse

Separate datastore for devices?

Open
#12,906 0 comments 0 reactions 0 assignees View on GitHub
A-Database A-Device-List-Tracking T-Enhancement
Dominant language
Python
Stars
4.6k
Forks
600
Avg merge
5d 22h
Merged PRs (30d)
51

Description

This issue has been migrated from [#12906](https://github.com/matrix-org/synapse/issues/12906).

---

**Description:**

We are currently experimenting with different ways to scale out the synapse database in particular where it would be possible to divide tables amongst separate database instances, much like the state tables/datastore class.

Based on my analysis it should be possible to extract the following device/e2e related stores into a separate datastore instance:

+ `Device*Store` (`stores/main/devices.py`)
+ `DeviceInbox*Store` (`stores/main/deviceinbox.py`)
+ `EndToEndKey*Store` (`stores/main/end_to_end_keys.py`)
+ `ClientIp*Store` (`stores/main/client_ips.py`)

I picked these because they're fairly small overall/low inter-dependency and represent a high percentage of database IO on our instance (currently single database all tables).

Note: the one interdependency this misses is the [`populate_monthly_active_users` call in `client_ips.py`](https://github.com/matrix-org/synapse/blob/28989cb301fecf5a669a634c09bc2b73f97fec5d/synapse/storage/databases/main/client_ips.py#L598) which could become `self.hs.get_datastores().device.populate_monthly_active_users(user_id)`.

Is there any appetite for this? We can commit engineering time to implement this if so. Also keen to discuss any other groups of stores that may be suitable candidates.

Contributor guide

Open the contributing guide

Research direction

Start by reading stores/main/devices.py, deviceinbox.py, end_to_end_keys.py, and client_ips.py, then inspect the populate_monthly_active_users call in client_ips.py. The issue proposes separating these stores but does not define an agreed design or acceptance criteria, so confirm the intended datastore boundaries and migration plan before implementation.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend, databases, distributed-systems
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.