# PostgreSQL 18 update for self-hosters

**URL:** https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194
**Category:** Announcements
**Created:** [August 3, 2026, 4:36am UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194 "2026-08-03T04:36:42Z")
**Posts on this page:** 1
**Showing post:** 30

<div class="post-metadata">

### Author: ![chrisr](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/chrisr/32/246622_2.png) [@chrisr](https://meta.discourse.org/u/chrisr)
#### Post date: [August 4, 2026, 12:45am UTC](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194/30 "2026-08-04T00:45:47Z")

</div>

> [@pfaffman](#):
>
> It’s actually pretty supported, it’s much safer than upgrading a database major version.

True, but we’re aiming for a simple transparent upgrade mechanism. There are merits both ways.

I’d say do whatever you’re comfortable with and don’t be afraid to customise the templates in discourse\_docker as your needs require. Obviously the key is to test first and have a rollback plan.

> [@Firefishy](#):
>
> Not sure the reason, but the [PostgreSQL 18 upgrade disables the native data checksums](https://github.com/discourse/discourse_docker/blob/e071c2c8ebf8a93c1fba4e16fbb7168a2a9201bd/templates/postgres.18.template.yml#L83). PostgreSQL data checksums a default feature and it seems very unusual to disable them.

On our hosted platform we intend to do more testing and benchmarking before switching these on, and so I disabled them in discourse\_docker as well to align the config. It’s not strictly necessary to disable them though (we only use the web container portion of discourse\_docker internally) and I wouldn’t be against enabling them.

One potential gotcha is that pg\_upgrade will not work if the old and new data directories have different checksum settings. The process would have to be to shut down the PG15 server, run pg\_upgrade to convert it to PG18 without checksums, run pg\_checksums to enable checksums and then start up PG18. This isn’t a problem when doing a dump and restore (as with this upgrade) but is something to watch out for.

Note that data checksums have been available since Postgres 9.3 but until now have been disabled by default. Postgres 19 will also include the ability to enable/disable them online.

> [@elmuerte](#):
>
> Just to confirm, I’m not using PostgreSQL provided by Discourse and Discourse itself does not require PG18 yet, right? So I am not (yet) required to upgrade to PG18.

Not at this time, no. Most of the Discourse functionality uses the Rails PostgreSQL adapter to talk to the DB, but backup/restore uses pg\_dump and psql in the web container. Right now we’re installing both PG15 and PG18 clients to enable backup/restore using both of these versions, but at some point in the future we’ll remove PG15.

> [@pfaffman](#):
>
> They pushed for . . . uh, some release pretty quickly after the update because of some feature that was required

The driving factor was switching to the new builtin locale provider. We are working towards an OS upgrade on our hosted platform and want to break the coupling with glibc.

---

_[View the full topic](https://meta.discourse.org/t/postgresql-18-update-for-self-hosters/406194)._