Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v8lo2-002p4S-WB for pgsql-admin@arkaria.postgresql.org; Tue, 14 Oct 2025 20:39:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v8ln3-002TKV-VC for pgsql-admin@arkaria.postgresql.org; Tue, 14 Oct 2025 20:38:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v8ln3-002TKN-HC for pgsql-admin@lists.postgresql.org; Tue, 14 Oct 2025 20:38:36 +0000 Received: from jakobs.com ([85.214.83.89] helo=plausibolo.de) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1v8ln0-002BUL-0G for pgsql-admin@lists.postgresql.org; Tue, 14 Oct 2025 20:38:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=jakobs.com; s=default; t=1760474312; bh=6MBljEJ6QHhZv1TkwHiYmTmGFMtiVBxJdbtv9RT/7Xg=; h=Date:Subject:To:References:From:In-Reply-To:From; b=TaviSGEJGTviR6CepAK0iPbxWgkZj72wIOnoOfEPiqZi1Lc3FrRyjzI6Vo3s1sS5m zzciN6eey6l10uSCfrULQiksm8vw42fE/8QEMhGEp/BM5QThhAa10GgB1+M4+nH6ao CK5wZK0CMM/i0lwWb+0WoK6KB6RN+rl30vMqbVetT1qDEVI5EP+2RR1aSZq+S6iwi+ XyZKEUBjr4/1x895720sZuMV7srnkak5amTfyV1WDqujmUbWI0OoTCt8LYLqj1DqHl Tt9BagQyRjM7jzcbK8amuUKb+ZTRZFaPw6lW2Z2X0dKkm1blxov6A1BFeR7xyCKmMg XMj0F5hIJZQPg== Received: from localhost (localhost [127.0.0.1]) by rs.plausibolo.de (Postfix) with ESMTP id D0BCB380BD8; Tue, 14 Oct 2025 22:38:32 +0200 (CEST) Received: from plausibolo.de ([IPv6:::1]) by localhost (h2367442.stratoserver.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id oB3592Hxunvx; Tue, 14 Oct 2025 22:38:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=jakobs.com; s=default; t=1760474305; bh=6MBljEJ6QHhZv1TkwHiYmTmGFMtiVBxJdbtv9RT/7Xg=; h=Date:Subject:To:References:From:In-Reply-To:From; b=LEAuBbocW8ZrofO7jXub+OCXVnwDmoH+NwQipe6u1cPHXqP+Qtdknd3gMjIkEUI5w JUc7wb9J6JVct7pi3aSccO0eNQXFM2mqagiLTniYZK7x8LDqzUSY4sZ+8oJkVhLeto rmGR20TeESCb6LN/fdnvWw1mBUSN73jQSSFjW0D7CIbzxHj4VlYGqeQ9+hLuQsYZcE WENAxgfhrdifq70H9dcyBsy8vrMw229IG2e83XPmDhNbTxfFW/LGgI/diLC0nwzbRg YCFdKS9aJqnZlS3iVEgKiUwImU6nlXDGnfYxIFjD8pM3xEAIlV+WWmB92a9P5ggVAr C/BcmiYiSS9EQ== Received: from [192.168.178.88] (xdsl-87-78-120-192.nc.de [87.78.120.192]) by rs.plausibolo.de (Postfix) with ESMTPSA id 749653808B4; Tue, 14 Oct 2025 22:38:25 +0200 (CEST) Content-Type: multipart/alternative; boundary="------------xLcSRRL0EuCB8dvIzSv00xsE" Message-ID: <07030892-d801-4d04-a506-24149186cd50@jakobs.com> Date: Tue, 14 Oct 2025 22:38:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Postgres Resource Sizing To: pgsql-admin@lists.postgresql.org References: From: Holger Jakobs In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------xLcSRRL0EuCB8dvIzSv00xsE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Am 14.10.25 um 22:32 schrieb Sam Stearns: > Howdy, > > We have an Oracle database that is processing 500 transactions per > second during peak hours.  We are migrating this to a Linux VM running > Postgres 17.6.  Is there anything out there that can give > recommendations on CPU / memory / shared_buffer sizing based on number > of transactions per second rate?  PGTune doesn't seem to have number > of transactions per second as an option. > > Thanks, > > Sam > Hi Sam, The number of TPS you can achieve depends mainly on your (virtual) hardware, except that version 18 of PostgreSQL offers some improvements like asynchronous I/O. PGTune tells you how to configure your system to get the best results, depending on your type of workload (web, oltp, dw, ...) using the properties of your hardware. 500 TPS doesn't seem much, so that should be easily achievable with almost any system, but of course it depends on the size of the transactions. Have you had any issues? It's quite likely that 500 TPS can be performed without any tuning at all, although I wouldn't recommend that. Kind Regards Holger > -- > > Samuel Stearns > Team Lead - Database > c: 971 762 6879 |o: 971 762 6879 |DAT.com > > > > -- Holger Jakobs, Bergisch Gladbach, Germany --------------xLcSRRL0EuCB8dvIzSv00xsE Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Am 14.10.25 um 22:32 schrieb Sam Stearns:
Howdy,

We have an Oracle database that is processing 500 transactions per second during peak hours.  We are migrating this to a Linux VM running Postgres 17.6.  Is there anything out there that can give recommendations on CPU / memory / shared_buffer sizing based on number of transactions per second rate?  PGTune doesn't seem to have number of transactions per second as an option.

Thanks,

Sam

Hi Sam,

The number of TPS you can achieve depends mainly on your (virtual) hardware, except that version 18 of PostgreSQL offers some improvements like asynchronous I/O.

PGTune tells you how to configure your system to get the best results, depending on your type of workload (web, oltp, dw, ...) using the properties of your hardware. 

500 TPS doesn't seem much, so that should be easily achievable with almost any system, but of course it depends on the size of the transactions. Have you had any issues?

It's quite likely that 500 TPS can be performed without any tuning at all, although I wouldn't recommend that.

Kind Regards

Holger



--

Samuel Stearns
Team Lead - Database
c: 971 762 6879 | o: 971 762 6879 | DAT.com


--

Holger Jakobs, Bergisch Gladbach, Germany

--------------xLcSRRL0EuCB8dvIzSv00xsE--