Migrate Synapse from SQLite to PostgreSQL: what the move involves
The move from SQLite to PostgreSQL is done with the synapse_port_db script that Synapse documents, run in two phases: first the script ports an offline copy of the SQLite database, then you shut the homeserver down, rerun the script for the data written since that snapshot, and restart Synapse on PostgreSQL. The effort is driven by four things: the size of the database, the disk headroom available for the new database, whether the Synapse release and the PostgreSQL major version you pick are compatible with each other, and how long a downtime window your users and federation peers can tolerate. Only the final phase touches live users, so the window you agree on should cover that phase and the restart checks, not the whole port.
This section covers the database port only. Authentication moves to Matrix Authentication Service, bridges, clients and reverse proxy changes are covered in their own sections or elsewhere on this page. If your homeserver also has an authentication migration planned, decide the order before the cutover, because each step changes what the server is running on when you cut over. Plan the two migrations as separate change records with separate rollback points, even if you execute them in the same maintenance window.
Start by confirming the PostgreSQL version your target Synapse release requires. Synapse documents a minimum PostgreSQL version for each release line, and it drops support for PostgreSQL versions once they reach upstream end of life. Check the supported PostgreSQL release calendar against your planned go-live date, since a version that is supported today may be near its end of support by the time you finish the migration. Also confirm the Python version your Synapse release needs. The Synapse upgrade notes explain that rolling back after a schema change can be difficult, so treat the port as a one-way change and keep a restorable copy of the SQLite file and its configuration.
Measure the SQLite file and the free space on the volume that will hold PostgreSQL before you schedule anything. The Synapse documentation notes that the database may grow by 25% to 100% after porting, so size the target volume for the upper end of that range plus room for write-ahead logs, backups and growth during the window. Also check that the SQLite database has auto_vacuum disabled, because the port script verifies that setting, and make sure nothing in your backup or maintenance jobs runs VACUUM against the SQLite file between the snapshot and the cutover. Ask your team to confirm whether any scheduled job, monitoring check or manual command touches that file.
Before you agree to a window, run the port against a copy of production data on a staging host with the same storage class and Synapse configuration. Record how long the first phase took, how long the delta run took, and how long Synapse needed to start on PostgreSQL. Those three timings define the downtime window far better than any estimate, and they show whether the script can be killed and restarted safely at each step on your data. The output of the rehearsal should also list the checks you will run after the restart and the person who signs off on them.
What maps cleanly from SQLite to PostgreSQL and what needs decisions
This table compares the SQLite-backed Synapse setup with its PostgreSQL equivalent, row by row, and shows what the port script handles and what your team must decide. Read each row across all three columns before you schedule the snapshot. The main takeaway is that moving the data is the simpler part, while the version floor, PostgreSQL major version, disk headroom and the VACUUM rule drive most of the planning.
| Area | What carries over or the port script handles | What the team must decide or confirm |
|---|---|---|
| Database file and backups | The port script copies data from an offline SQLite snapshot into PostgreSQL, and can be rerun against newer snapshots. | Decide where the SQLite file and its backups are kept until PostgreSQL backups are set up and restore-tested. |
| Maintenance routines | The script checks that auto_vacuum is disabled on the SQLite file. Never VACUUM that file between runs. | Define PostgreSQL backup, continuous archiving and point-in-time recovery, and test a restore before cutover. |
| Connection handling | SQLite runs inside the Synapse process, so there is no database connection to manage today. | Decide how Synapse connects to PostgreSQL, and whether a pooler such as PgBouncer is needed. Confirm settings in the Synapse PostgreSQL docs. |
| Worker topology | Data is shared by the main process and workers, and Redis relays replication between processes. | Confirm which processes connect to the database and Redis in the target layout, and test that layout before cutover. |
| Synapse version floor | The same Synapse release family can run on either backend, so the code path is not changed by the port itself. | Synapse 1.143.0 and later require PostgreSQL 14 or newer. Pick the release first, and plan for limited rollback after schema changes. |
| PostgreSQL major version | No data carries over unchanged. The port creates a new database cluster on the chosen version. | PostgreSQL 14 support ends November 12, 2026. Version 18 is supported until November 14, 2030, per the PostgreSQL versioning policy. |
| Disk space | The data set itself is the same, but PostgreSQL stores it differently. | Plan for 25% to 100% more disk space after porting, as the Synapse docs note. Measure your own database size before choosing storage. |
| Media storage and signing keys | The port script works on the database. It does not move media files or change signing keys. | Confirm in the Synapse docs for your release whether media paths and signing key locations stay where they are, and plan them separately. |
Which documented tools move the Synapse database
The move has three layers: the script that copies data, the Synapse documentation that defines the target setup, and the PostgreSQL tools your team will rely on after cutover. Each layer has its own checks, and the script's behavior should be confirmed against the Synapse release you run.
synapse_port_db script
The script ports a SQLite-backed Synapse to PostgreSQL in two phases. First it ports an offline copy of the SQLite database. Then, during a planned stop, you rerun it for data added since that snapshot and restart Synapse on PostgreSQL. It can be run repeatedly against newer snapshots and restarted after an interruption. Before it copies data, it checks that auto_vacuum is disabled on the SQLite database. Confirm these checks and options against the Synapse release you run.
Synapse PostgreSQL documentation
The Synapse Using Postgres page defines the database setup the port should target. Version floors change between releases: Synapse 1.143.0 and later require PostgreSQL 14 or newer. Check the upgrade notes for the release you plan to run, and confirm the target server meets that floor before the first port starts. Record the database settings Synapse expects in your runbook so the production build matches the documented setup.
Backups and point-in-time recovery
Continuous archiving and point-in-time recovery let you restore the new PostgreSQL database to a chosen moment. This matters during a migration because the SQLite file stays your fallback until cutover is verified. Take a base backup and confirm WAL archiving works before the first real port, then restore a copy into a test environment. Ask who owns restore testing and how long a restore takes in your environment, since the documentation does not set that for you.
Connection pooling with PgBouncer
PgBouncer is a lightweight connection pooler for PostgreSQL. Synapse runs a main process and may run several workers, and each process holds database connections, so connection limits become a concern as traffic grows. Decide whether a pooler sits in front of the database, then confirm in the Synapse documentation which pooling modes and settings apply to your configuration. Load test with expected client and federation traffic before go-live.
Major upgrades after cutover
PostgreSQL releases a new major version about once a year and supports each one for five years after its initial release. Supported versions include 14, which is supported until November 12, 2026, and 18, first released September 25, 2025. Plan the upgrade path before go-live: pg_upgrade, dump and restore, or logical replication, which PostgreSQL documents as allowing major upgrades with only several seconds of downtime. Confirm which Synapse releases support your target major version.
How the two-phase snapshot approach limits downtime
The two-phase approach separates the slow work from the short outage. In the first phase, you port an offline copy of the SQLite database to PostgreSQL with the synapse_port_db script while the live homeserver keeps running on SQLite. Users keep sending messages and joining rooms during this phase because the production server does not change. The copy is a snapshot, so it captures the data as it stood when the copy was taken. Before you start, confirm where the snapshot will be taken from, how long the port takes on a copy of your production database, and that the PostgreSQL server runs a version your Synapse release supports. Those checks turn phase one into a rehearsal your team can repeat.
The second phase is the cutover. You shut down Synapse, including any worker processes, so no new writes reach the SQLite file. You then rerun the script, which carries over only the data added since the snapshot, and point the homeserver configuration at PostgreSQL. Restart the server only after the delta run completes and the script's checks pass. Decide in advance who signs off the cutover, what the rollback path is before anything in the SQLite setup changes, and who monitors the first hour after restart. Write these decisions into the runbook so the on-call engineer does not have to work them out during the outage.
Because the script can be run repeatedly against newer snapshots and killed and restarted safely, the team can plan several runs. A rehearsal can port a snapshot, cut over to a test PostgreSQL instance, and then repeat with a newer snapshot to see how long the delta run takes. If a run takes longer than the window allows, you can stop it and start again without corrupting the target. One constraint applies throughout. The Synapse docs warn that the SQLite database must never be VACUUMed between runs, and the script checks that auto_vacuum is disabled. Put that restriction in the runbook and in the change ticket so an operator or a maintenance job does not run it on the source file.
The length of the final downtime depends on how much data arrives between the snapshot and the cutover. The longer the gap, and the busier the rooms during that gap, the more rows the delta run must move while Synapse is stopped. Shutdown, the delta run, the configuration change, restart and health checks all fall inside the window, but only the delta run grows with activity. Illustrative example: a snapshot taken the evening before a cutover on a quiet server leaves a small delta, while a snapshot taken at the start of a busy workday leaves a large one. Those two cases can produce very different outage lengths on identical hardware.
Measure the window on your own data. Run at least one full rehearsal on a copy of your database, on the same hardware and PostgreSQL version you plan to use in production, and record the duration of each step separately. Compare the delta run time with the number of events written during the gap so you can estimate the window for your actual cutover date. Ask your implementation partner to include rehearsal runs and timing in the written scope, and confirm with your change board how long a maintenance window you can accept. Timings you measured on your own data are the only figures that should appear in your change request.
How the Synapse port runs from inventory to decommission
The sequence moves the homeserver from an offline snapshot to a validated PostgreSQL database and ends with a documented decommission of the SQLite file. Each step has an owner and a check that must pass before the next one starts. The SQLite copy stays as the reference and fallback throughout, and it is never written to alongside PostgreSQL.
Inventory the homeserver before any copy
The team records the Synapse version, the homeserver configuration, the SQLite database size, the media store locations and the worker layout, including any Redis and replication settings. The Synapse version sets the PostgreSQL floor, since Synapse 1.143.0 and later require PostgreSQL 14 or newer, so the version check comes first. DeployOpen engineers also confirm whether auto_vacuum is set on the SQLite file, because the port script checks for it. The step closes with an inventory that the client approves, which becomes the baseline for every later run.
Build the PostgreSQL target
DeployOpen builds a PostgreSQL instance in the client's infrastructure on a major version that Synapse supports and that is still inside its PostgreSQL support window, and checks the current Synapse release notes for the floor. Storage is sized for the database growing by 25% to 100% after porting, according to the Synapse docs, with headroom for media and backups. The team applies the database settings the Synapse PostgreSQL guide documents and tests a connection from the Synapse host. The step is done when an empty database accepts that test connection and the storage plan is approved.
Run a pilot port on an offline copy
The team stops Synapse or takes a consistent copy of the SQLite file and runs synapse_port_db against that copy, never against the live database. The script checks that auto_vacuum is disabled, and the team confirms that nothing runs VACUUM on the SQLite file during the port. Once the run completes, DeployOpen starts Synapse against the pilot PostgreSQL database and compares row counts and sample room, user and media records with the SQLite copy. The step closes with a pilot report listing the errors found, the time the run took and any configuration changes needed.
Rehearse the final delta and restart
Using the pilot as a template, the team rehearses the cutover on a copy of production data. The port script runs again against a newer snapshot to pick up rows added since the first pass, then Synapse is shut down, the delta runs and the configuration switches to PostgreSQL before restart. The script can be run repeatedly and safely killed and restarted, so the team can measure the delta against the agreed window and repeat the run if it overruns. Each rehearsal produces a timed runbook with exact commands, owners and the checks that gate each stage.
Validate on the test copy
The test copy runs on PostgreSQL for a validation period the client agrees in advance, while the SQLite file stays untouched. The team checks user logins, room history and state, federation with the agreed peers if it is enabled, media retrieval, worker health and admin API tasks, and records each result. Validation queries run only against PostgreSQL, so the SQLite file remains a fixed reference for comparison. The step is complete when the client's application owner signs off the results and every defect found in rehearsal has a fix that passed a second rehearsal.
Cut over during the agreed window
In the agreed window, Synapse stops, the final delta runs against the SQLite file, the configuration switches to PostgreSQL and Synapse restarts. The SQLite file is the reference and fallback only. Synapse writes to one database at a time, so no change is copied in two directions. The Synapse upgrade notes warn that rolling back can be difficult because of schema changes, so the rollback point is agreed before the window opens, and anything written to PostgreSQL after cutover would be missing from the SQLite file. The step closes when Synapse is healthy on PostgreSQL and the client accepts the cutover in writing.
Decommission SQLite after the retention period
After the retention period the client sets, the team confirms that PostgreSQL is the only source of record and takes a verified backup of the PostgreSQL instance. The SQLite file is then archived and the Synapse configuration that points to it is removed. Archive location, encryption and access are agreed with the client, because the file holds personal data and message history. The step closes with a decommission record listing the dates, the archive location, the approver and the backup that was verified.
Why VACUUM on SQLite breaks repeat runs and how much disk PostgreSQL needs
Do not run VACUUM on the SQLite database between port runs. The Synapse documentation says the SQLite database must never be VACUUMed between runs of the port script, and the script checks that auto_vacuum is disabled before it starts. Both checks guard the same problem. Each run reads a snapshot, and a later run depends on the state the earlier run left in the file, so a VACUUM can invalidate the chain of snapshots you are building. The risk is usually routine maintenance, not a deliberate decision. A homeserver's database sits in a data directory managed by a service, and it is easy to miss when someone adds a scheduled VACUUM, a database tidy-up job or a backup hook that rewrites the file. Before the first snapshot, inspect cron jobs, configuration management and backup tooling on the host, exclude the file from any of them, and name the person who approves changes to that host.
If a repeat run fails with an auto_vacuum message or the chain looks inconsistent, stop and investigate. Do not work around the check. Find out whether anything touched the SQLite file after the last good run, and check the Synapse documentation for the version you run to confirm the recovery path. Plan the cutover window with this in mind. Each additional snapshot run adds time to the cycle, so a VACUUM discovered late can cost a rerun during your downtime window. Ask your team to confirm, in writing, that the maintenance schedule has been reviewed and that the SQLite file is read only by the port process and the running homeserver, as far as the homeserver's own operation allows.
The Synapse documentation notes that the database may take 25% to 100% more disk space after porting to PostgreSQL. Use that range as the starting point for capacity planning, and replace it with a figure from your own environment as soon as you can. Measure the size of the SQLite database file on the homeserver, along with the free space on the volume that will hold PostgreSQL. As an illustration only, a 40 GB SQLite file would suggest planning for roughly 50 GB to 80 GB of database storage. Media is stored separately from the database, so size the media store on its own measured usage. Confirm with your Synapse version whether any background database updates run after the port and how much temporary space they need, because that can change the peak you should plan for.
Size storage for PostgreSQL write-ahead logging and backups as well as for the database itself. WAL segments accumulate with write volume, and continuous archiving and point-in-time recovery depend on keeping archived WAL for as long as your recovery objectives require. Backup storage therefore grows with the rate of change in your homeserver and with the retention you choose, and neither figure is supplied for your deployment. Measure WAL generation during a rehearsal that resembles production traffic, then set retention with your recovery and compliance owners. Keep the SQLite file and a verified copy until the PostgreSQL cutover has run cleanly for an agreed period. In the quote, ask who provisions and expands the storage, how volumes can grow without downtime, where backups are stored, and how restore tests are scheduled.
What drives the cost and duration of a Synapse PostgreSQL port
This table lists the factors that raise or lower the effort of moving a Synapse homeserver from SQLite to PostgreSQL. Read each row as a question to answer about your own server before you ask for a quote, because the answers decide how many snapshot passes, rehearsals and recovery checks the work needs.
| Driver | What raises effort | What lowers effort |
|---|---|---|
| Database size and growth rate | A large SQLite file, heavy message volume or a busy federation load makes each snapshot slower to port and widens the gap the final delta pass must close. | A smaller database with modest daily growth shortens each port pass and keeps the final cutover delta small. |
| Free disk and backup capacity | Little free space for the PostgreSQL cluster, the SQLite snapshot and a fresh backup, since the database may grow 25% to 100% after porting (Synapse docs). | Enough headroom for the new cluster, the snapshot and a verified backup before the first run starts. |
| Synapse and PostgreSQL version compatibility | Running a Synapse release that needs a newer PostgreSQL than the one you plan to deploy, or an end-of-life PostgreSQL version, forces an extra upgrade step. | A current Synapse release paired with a PostgreSQL major version still in upstream support, confirmed against the upgrade notes before the port. |
| Worker topology and Redis | Multiple workers, a separate Redis instance and replication settings that must be reconfigured to point at the new database. | A single process with no workers, or a worker setup already documented and tested, leaves fewer components to repoint. |
| Agreed downtime window | A short window that allows only the final delta pass and restart, which needs more rehearsal and a tighter cutover checklist. | A window long enough to run the full delta and restart calmly, with a rollback point agreed with the business owner. |
| Number of rehearsals required | Several rehearsals on a copy of production data, especially if the database is large or the topology is complex. | A single rehearsal on a representative copy that has already passed the integrity and sampling checks. |
| Backup and point-in-time recovery readiness | No tested backup of the SQLite file or no point-in-time recovery plan for the new PostgreSQL cluster, so every step carries more risk. | Existing backups restored successfully in a test environment and continuous archiving configured before cutover. |
| Operator experience with Synapse and PostgreSQL | No one on your team has run Synapse upgrades or PostgreSQL administration, so more of the work and knowledge transfer falls to the partner. | A team that already operates both platforms and can own the runbook, monitoring and post-cutover tuning. |
What usually goes wrong in a SQLite to PostgreSQL port
Most failed ports come from a small set of avoidable mistakes: changing the source file during the two-phase process, underestimating storage, choosing a database version that is leaving support, and cutting over without a rehearsal, a tested backup or a workable rollback path. Each card names one failure mode and the step that prevents it. Work through them before the first run so the snapshot, delta and cutover steps are planned as one sequence.
Maintenance on the SQLite file
Running VACUUM, or any tool that rewrites the SQLite file, between port runs can break the copy. The Synapse documentation says the SQLite database must never be VACUUMed between runs, and the synapse_port_db script checks that auto_vacuum is disabled. Before the first run, confirm that no scheduled job, backup agent or operator habit touches the file, and keep a separate copy of the snapshot so the source stays untouched for the whole port window.
Running out of disk space
The Synapse documentation notes that the database may take 25% to 100% more disk space after porting to PostgreSQL. Running out during the port leaves a partial database, and running out after cutover can stop writes on a live server. Size the PostgreSQL volume from the current SQLite file size using that range, then add room for indexes, write-ahead logs and growth, and check free space before every run.
Targeting an unsupported PostgreSQL version
PostgreSQL 14 support ends November 12, 2026, and Synapse 1.143.0 and later require PostgreSQL 14 or newer. A port to 14 can leave the server on an unsupported database soon after cutover. Confirm the target major version against the PostgreSQL versioning policy on the day you plan the port, and check the Synapse upgrade notes for the Synapse release and Python version you will run.
Skipping the delta rehearsal
The cutover step reruns the script for data written since the snapshot, and its run time depends on how much changed during the snapshot phase. Teams that run the delta for the first time during the outage often find timing problems and errors they did not see earlier. Rehearse the full two-phase sequence on a copy of the server, time each step, and write the exact commands into the cutover runbook so production repeats a tested sequence.
No tested backup before cutover
A backup only counts after a restore has succeeded. Before cutover, back up the SQLite database, the Synapse media store and the configuration files, and back up the PostgreSQL target after the first load. Restore those backups into a separate environment and start Synapse against the restored copy. For PostgreSQL, confirm that continuous archiving and point-in-time recovery are set up and that a recovery has been tested.
A rollback blocked by schema changes
The Synapse upgrade notes warn that rolling back can be difficult because database schema changes occur between releases. Once the server runs on PostgreSQL and applies newer schema changes, returning to an earlier Synapse release or to the SQLite database may require restoring data from backup. Record the Synapse version before and after the port, keep the SQLite file and a PostgreSQL backup until the new setup is accepted, and set the rollback decision point in the change plan.
Questions buyers ask before porting Synapse to PostgreSQL
What drives the cost of porting Synapse from SQLite to PostgreSQL?
The cost depends on the scope you agree in writing before work starts. The main drivers are the size and age of the SQLite database, how many rehearsals the port needs, the state of your hosts and network, and how much surrounding work is included, such as PostgreSQL provisioning, backup changes and verification. DeployOpen's engagements are fixed-scope, and a quote follows from that written scope. Ask each bidder to itemize planning, rehearsals, cutover support, verification, documentation and handover. Separate one-time work (the port itself) from recurring costs, which come from running PostgreSQL afterward: backups, patching, minor-version updates and monitoring. Those can move to a retainer if you choose one. Ask who provisions the extra disk and who pays for it.
How long does a Synapse PostgreSQL port take, and how much downtime should we expect?
Downtime depends on how much data changes between the first snapshot and cutover, and on what your rehearsals measure. The documented method ports an offline copy of the SQLite database first. Then you shut Synapse down, rerun the script to pick up data added since the snapshot, and restart on PostgreSQL. A busy homeserver with many rooms and frequent writes produces a larger delta, so the final stop is longer. The size of the database alone does not predict the stop. Ask the partner for the number of timed rehearsals on a copy of your data, the measured time for each phase, the delta expected at cutover, and the rollback point. Do not accept a downtime figure that no rehearsal has produced.
What does a Synapse PostgreSQL migration need from our team?
Your team provides access, a window, safe copies and a named decision owner. Plan for administrator access to the Synapse host, the PostgreSQL server and the configuration files. Agree a maintenance window with the users affected. Take a verified backup of the SQLite database and the media store before any port run. Synapse documentation notes that PostgreSQL may need 25% to 100% more disk space after porting, so size the target volume against that range using your own database, and keep room for the SQLite files during the migration. Name one owner who approves cutover, answers questions about DNS, identity and federation settings, and signs off the verification checks. Decide in advance who watches the server after go-live.
Can our own team port Synapse to PostgreSQL without an outside partner?
Yes, a team with Linux, PostgreSQL and Synapse operations experience can run the documented path. The Synapse documentation describes the synapse_port_db script and the two-phase approach. Success depends on a rehearsal on a copy of production, a tested rollback plan and a written cutover checklist. A partner helps when the team lacks PostgreSQL or Synapse operations experience, when the deployment is large or heavily customized, when the cutover date is fixed, or when you need documented evidence for a compliance assessment. Check the platform floor first. Synapse 1.143.0 and later require PostgreSQL 14 or newer, and PostgreSQL 14 is supported until November 12, 2026. PostgreSQL 17 and 18 give a longer support runway.
Does porting Synapse to PostgreSQL affect a later move to Matrix Authentication Service?
The port changes where data is stored, not the login method, but it changes the order of work. Complete the PostgreSQL port first, verify it, and keep it stable. Then plan the move to Matrix Authentication Service as a separate change with its own readiness checks, dry run and downtime window. The sibling page on migrating Synapse authentication to MAS with syn2mas covers those steps. Doing both in one window doubles what can fail at once and makes it hard to tell which change caused a fault. Before you schedule the second cutover, confirm in the MAS and syn2mas documentation which database state the tool expects, and retest your backups on the PostgreSQL side.
Why must we never VACUUM the SQLite database before porting Synapse?
Running VACUUM on the SQLite database between port runs can break the port. The Synapse documentation warns against it, and the port script checks that auto_vacuum is disabled, so a changed setting can stop the run. Treat the SQLite file as read-only for the whole migration. Do not run maintenance jobs against it, do not copy it while Synapse is writing, and do not change its auto_vacuum setting. If an earlier administrator ran VACUUM or changed the database settings, ask for that history before you start, and take a fresh snapshot after you confirm the settings. Put this check in the written cutover checklist and repeat it in every rehearsal.
Can we roll back from PostgreSQL to SQLite after upgrading Synapse?
Usually not easily, so plan the rollback before cutover. The Synapse upgrade notes warn that rolling back can be difficult because database schema changes between releases are not undone by an older version. Once a newer Synapse has migrated the PostgreSQL schema, an older release may fail to start against it. The SQLite copy also goes stale as soon as users write to PostgreSQL. Keep the SQLite database and configuration unchanged for a period you set in advance, take a backup before each Synapse upgrade, and rehearse the restore path. Make upgrade decisions only after the port is verified. Ask the partner to document the exact rollback steps for each Synapse version you plan to run.
How DeployOpen scopes, runs and supports the Synapse port
DeployOpen plans and runs the move of a self-hosted Synapse homeserver from SQLite to PostgreSQL inside infrastructure you control. The work follows the two-phase snapshot method documented for synapse_port_db, with the cutover, verification and handover written down before any production step starts.
How we scope
- The written scope lists the Synapse version, the SQLite database size, the target PostgreSQL version and the hosts involved.
- We confirm the cutover window, the rollback point and who on your side approves the final switch.
- We agree on disk headroom for PostgreSQL, using the 25% to 100% growth range the Synapse docs note as the planning basis.
- Engagements are fixed-scope, and ongoing support after the port is available as a retainer.
How we build
- We check auto_vacuum settings and confirm nobody runs VACUUM against the SQLite file between port runs.
- We run the offline snapshot port on a copy first, then record row counts and errors for review.
- We rehearse the final delta port and restart on PostgreSQL in a non-production environment before production.
- We verify federation, media access and client login against the restarted homeserver before sign-off.
How we hand over
- You receive the runbook with the exact commands, sequence, checkpoints and the rollback procedure used.
- The documentation records the final Synapse and PostgreSQL versions, connection settings and backup locations.
- We walk your operators through the restart, the monitoring checks and the known warnings from the port run.
- Retained SQLite backups and their retention period are listed so your team knows what can be deleted and when.
How we support
- Post-cutover support covers monitoring of database growth, connection health and Synapse log errors during the first weeks.
- Upgrade planning for later Synapse and PostgreSQL releases is included in the retainer scope when you choose one.
- Backup and point-in-time recovery testing for the new PostgreSQL cluster can be added to the support scope.
- Confirm with your PostgreSQL and Synapse vendors which versions are still supported before you agree the upgrade calendar.
