MIME-Version: 1.0
From: Babak Ghadiri <bbkghadiri6@gmail.com>
Date: Fri, 2 Jan 2026 11:25:07 +0330
Message-ID: 
 <CAEkHFKSxYO7Ryv_UNNGSe88zosg0_Q_dop6hXN0oCoYK28EZtA@mail.gmail.com>
Subject: Parallelizing startup with many databases
To: pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000d6e6ff06476307c3"
Archived-At: 
 <https://www.postgresql.org/message-id/CAEkHFKSxYO7Ryv_UNNGSe88zosg0_Q_dop6hXN0oCoYK28EZtA%40mail.gmail.com>
Precedence: bulk

--000000000000d6e6ff06476307c3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,
I hope you are doing well.

In PostgreSQL 16, startup appears to initialize databases sequentially and
primarily uses a single CPU core. In clusters with a very large number of
databases (around 5,000 in our case), this results in noticeably long
startup times after restarts or crash recovery.

I would like to ask:

- Is the largely single-threaded startup behavior a fundamental
architectural
  constraint (e.g. catalog dependencies, locking, recovery ordering), or
mainly
  an unimplemented optimization?
- Are there any existing discussions, patches, versions (18+) to
parallelize parts of startup or otherwise improve startup scalability with
many databases?
- Are there any PostgreSQL configuration settings known to dramatically
reduce startup time, or is startup performance mostly fixed by architecture
in this scenario?

I understand that having many databases in a single cluster is not the most
common or recommended multi-tenant model, but this is an existing system an=
d
I=E2=80=99m trying to better understand the current limits and future direc=
tion.

Thank you for your time and insights.

Best regards.

--000000000000d6e6ff06476307c3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<br>I hope you are doing well.<br><br>In PostgreSQL =
16, startup appears to initialize databases sequentially and<br>primarily u=
ses a single CPU core. In clusters with a very large number of<br>databases=
 (around 5,000 in our case), this results in noticeably long<br>startup tim=
es after restarts or crash recovery.<br><br>I would like to ask:<br><br>- I=
s the largely single-threaded startup behavior a fundamental architectural<=
br>=C2=A0 constraint (e.g. catalog dependencies, locking, recovery ordering=
), or mainly<br>=C2=A0 an unimplemented optimization?<br>- Are there any ex=
isting discussions, patches, versions (18+) to parallelize parts of startup=
 or otherwise improve=C2=A0startup scalability with many databases?<br>- Ar=
e there any PostgreSQL configuration settings known to dramatically reduce =
startup time, or is startup performance mostly fixed by architecture in thi=
s scenario?<br><br>I understand that having many databases in a single clus=
ter is not the most<br>common or recommended multi-tenant model, but this i=
s an existing system and<br>I=E2=80=99m trying to better understand the cur=
rent limits and future direction.<br><br>Thank you for your time and insigh=
ts.<br><br>Best regards.<br></div>

--000000000000d6e6ff06476307c3--