Open edX on PostgreSQL

Choose the PostgreSQL major version only after confirming which versions the Tutor PostgreSQL plugin supports, because the plugin sets the boundary of your options. Then check the support window against the life you expect for this installation. PostgreSQL supports each major version for five years after its initial release, and the currently supported majors are 14 through 18. Your team should record the chosen version, its end-of-support date and the planned review date in the same change record as the Open edX release you are deploying.

The end-of-support dates are November 12, 2026 for PostgreSQL 14, November 11, 2027 for 15, November 9, 2028 for 16, November 8, 2029 for 17 and November 14, 2030 for 18. PostgreSQL 14 reaches end of support only a few months after Verawood was published on July 30, 2026, so a fresh installation on 14 would need an upgrade soon after launch. Ask the plugin maintainers whether they test against the newest PostgreSQL majors, and ask Edly or your implementation partner how long the plugin has supported each version. A version that is supported by PostgreSQL but not yet tested with the plugin is a risk you should accept only in writing.

Minor releases and major upgrades are different operations. A minor update replaces the server executables and restarts the service, and it does not change the internal storage format, so data files stay in place. Plan minor updates as routine maintenance in a window you can roll back. A major upgrade changes the storage format and needs one of three methods: a dump and restore with pg_dumpall, pg_upgrade, or logical replication from the old major to the new one. Logical replication can keep downtime to a short cutover, and the PostgreSQL documentation describes downtime of several seconds for this method, but your actual cutover time depends on write volume, extensions and how Open edX sessions are drained. Measure it in a rehearsal on a copy of production data.

PostgreSQL 18 changes the arithmetic for in-place upgrades. Its pg_upgrade retains planner statistics across the upgrade, so the database does not start with cold statistics, and it adds parallel jobs and a --swap option to shorten the process on large clusters. Those features do not remove the need for a tested rollback plan, a backup you have restored successfully and a verified list of extensions the new major supports. Because the plugin path covers fresh installations, treat any upgrade of an existing Open edX database as a separate project. Confirm with the plugin maintainers which upgrade procedures they support before you commit to a date.

High availability for an Open edX installation on PostgreSQL is a set of separate decisions, one per layer, and the database layer is the one most often assumed to be solved. PostgreSQL supports hot standby servers that serve read-only queries, along with synchronous replication, where a commit waits until standbys confirm it, and asynchronous replication, where it does not. These features reduce the risk of data loss and can offload reads. They do not, by themselves, provide automatic failover. The PostgreSQL documentation states that the server does not include software to detect a failed primary and notify a standby, so that job falls to external tools. Treat the database as one layer of the design, not as the whole answer.

If you need automatic promotion, the external tool becomes part of your production system, and it needs a named owner. Someone must decide how failure is detected, how the old primary is fenced so that two servers never accept writes, how the Open edX services learn the new primary's address, and who is alerted when promotion happens. Connection handling matters too. Applications holding connections to a failed primary need a way to reconnect, and a connection pooler such as PgBouncer changes where that reconnection happens. Write these steps down as a runbook before you test them, because a failover that has never been exercised is an unverified control.

The choice between synchronous and asynchronous replication is a trade-off to settle with the business before the build starts. Synchronous replication protects committed transactions such as enrollments, grades and certificate records, but every commit waits for standby confirmation, and if the standby is unreachable, writes can stall unless you have planned how the system should behave in that case. Asynchronous replication keeps the primary fast, but transactions committed just before a failure may not exist on the standby. Ask which Open edX data would be unacceptable to lose and how long learners can tolerate an outage, then match the replication mode and the failover design to those answers.

The Open edX side needs its own check. A multi-node deployment needs a shared Django cache backend, such as Redis or Memcached, so that every LMS and Studio node sees the same cached data. That cache is a second stateful dependency that can fail independently of PostgreSQL, so it needs its own availability plan. Confirm how Tutor handles the application tier in the setup you intend to run, including how multiple application replicas are deployed, where the cache and media storage run, and what changes in the application configuration when the database address moves during a failover. A database standby alone does not protect the whole platform.

Before you plan any standby or failover topology, confirm with the plugin maintainers whether that configuration is supported for a fresh install. The PostgreSQL plugin is a community Tutor plugin, and the setups it supports may be narrower than what PostgreSQL itself allows. Ask for the supported topology in writing, the Open edX and Tutor versions it was validated against, and any known limits on failover. If standby or failover is not supported, plan recovery instead, built on tested backups and point-in-time recovery, with recovery time and recovery point targets set by your organization in its own requirements.