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.96) (envelope-from ) id 1vQ59S-009GcJ-1d for pgsql-admin@arkaria.postgresql.org; Mon, 01 Dec 2025 14:45:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vQ59R-003GcT-0F for pgsql-admin@arkaria.postgresql.org; Mon, 01 Dec 2025 14:45:17 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vQ59Q-003Gc6-1t for pgsql-admin@lists.postgresql.org; Mon, 01 Dec 2025 14:45:17 +0000 Received: from mail-oa1-x34.google.com ([2001:4860:4864:20::34]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vQ59O-002aST-0G for pgsql-admin@lists.postgresql.org; Mon, 01 Dec 2025 14:45:16 +0000 Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-3ec4d494383so2731845fac.3 for ; Mon, 01 Dec 2025 06:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764600314; x=1765205114; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=D/pr9Vx6YcAU8/X7v+DPAEnTITVJJosNiXgVPqadR40=; b=S7yKYFz8XyZ7552pvfL/Xo2B3Lx+zJ08VMgi+p/KCzkiLndDEfEmlDe1dfIWwR64vi AKbU8p7cM5DQuIGJsjmMcOiQlNC5ebfZDDKp2yEXaU0MBkeoPMFFu5JauzvUnjtZ84fU s518n80Qx1kwaHGbtpDo+C+ySdnQry4NXh1PgmPFItkvFUcujRTjoOSR3/dhJT3Xv8E7 AgginbmmHehbvxU3VigFNNXVusddM+c/pN4iYhC9mmQgg9o1Tuw/yOo7XXIeN8t5juJj I4OAQz/C5fMYUmO9vV8LGMr5ctNkJ93HnbrOJqg3vSgaD8aqbRMKj/bFqyG1IdyX3ewn QnEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764600314; x=1765205114; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=D/pr9Vx6YcAU8/X7v+DPAEnTITVJJosNiXgVPqadR40=; b=q4OvPUMF+eRlZBAJOE4kCyTfasE/41iG0MReFMM4o1h3e+K+BGFzZx4ZBimpFeLIAi tZH3yYK6+ue/X6ePbjrO5cmaHLJ5fWiCfdo3FhdX7NNEDPvY/NF6MUgEUE8zfpdr6QJW OVb4mHeK4CPjmG8KADaItIjClLoP4xyOKZtgZ4C+P7UJvkQbvTD4MjBMLfoPjYl6+YTp NGLRD/uA6qLW5clerNm1yR25OsWsTMxlnF+7iaUqX6f4QVcNMK98I/kSATz2s2Jd0uuD i4NYTb0osvv/94jGX7G+Q3ntRemj7Cv4EF19WtbVTxa8vfPxXz0DQWYzKw1c76/aU/js dSPw== X-Gm-Message-State: AOJu0Yws6gMGVpT1a3znZV95ubYeuM7Xolf1GzezDuQdPVhJB7pL/E/r A9oY9RPwqlIf7uYe1Q80kVnRVr9MiOFcD6nZeaiUSMb+x7qzuJ3TWOqs5rDUP7gcFU460fBQRbB lmhTRt+MdPlwAJvrk54ZbPIsigqhPkTfiaA== X-Gm-Gg: ASbGnctfWE5meWVR69NhkC5/tLvbsIKI0n7VDivDqUuZyoEJzQW3DrjJ0CQhN8zx7Rj 3w3DGFn8HeL7nq6IXEi9MrOBXx+J91nVeoCQhAZDTYtQZRHt4umLMP2tpZlwlMmAf/XMWVivj/c B6kB3qkRVDAGvhPsM9Os6rdGGXnvPGm3aaEaWdVaPbfyw0qS2RvOg/D7pGHf8zBdbiEAIOhf7jo 8bzoOoVlk6NBljHXQ2Ui99fs6v9jDnVrlIsrfjNRxmKBOXpqxbTqB1ty3rr/RpztcivRAVN X-Google-Smtp-Source: AGHT+IEyuMFHYheA/G7gCsfPUv9pvm6HifYgKQMMi/BzKSO6L2rdghyxLkNsAXBWCwhkVw1mW14YlC8ZnGj9rAl87L8= X-Received: by 2002:a05:6871:292:b0:3ec:4e22:bbb3 with SMTP id 586e51a60fabf-3ed1fd50166mr12170079fac.1.1764600313959; Mon, 01 Dec 2025 06:45:13 -0800 (PST) MIME-Version: 1.0 References: <8db363787dc505e0dbe01ab48c437205928f1c2b.camel@cybertec.at> In-Reply-To: From: Ron Johnson Date: Mon, 1 Dec 2025 09:45:02 -0500 X-Gm-Features: AWmQ_bnUf0xHG9JuoPh_dF3C2RtMuyiHLwDhhbWMuqbV5AHEtAMSNRw-7JIYORw Message-ID: Subject: Re: Migration from MSSQL to POSTGRESQL To: Pgsql-admin Content-Type: multipart/alternative; boundary="000000000000e258ba0644e5068b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e258ba0644e5068b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In the one Oracle -> Postgresql migration I did (where I came in after the AWS RDS Postgresql VMs were already sped'ed and were 1:1 the same as the Oracle servers: - disk usage was 1/3 lower - both CPU and RAM were 75% over-specified. (They could be chopped in half and performance would still be good.) But, of course, your mileage not only might vary, but *it will vary*. On Mon, Dec 1, 2025 at 3:38=E2=80=AFAM Raj wr= ote: > Sorry, it's Oracle to POSTGRESQL migration. > > I apologize for the confusion. > > Please suggest based on Oracle. > > On Mon, 1 Dec 2025, 14:00 Tayyab Fayyaz, wrote: > >> Hello Raj, >> >> It really depends on how much of those 64 vCPUs and 250GB RAM your SQL >> Server actually uses today, and whether you=E2=80=99re running on a phys= ical box or >> a virtual machine. >> >> PostgreSQL doesn=E2=80=99t have a 1:1 sizing formula against SQL Server.= I=E2=80=99d >> first look at real CPU/memory usage, workload pattern (OLTP vs reporting= ), >> and how connections/queries behave. I=E2=80=99d also factor in how well = we can >> migrate and map the data types and queries, because good type choices an= d >> query rewrites can significantly reduce resource usage. >> >> - >> >> *If it=E2=80=99s a physical server*, I=E2=80=99d start with similar h= ardware for >> PostgreSQL and then tune Postgres parameters (shared_buffers, work_me= m, >> etc.) based on monitoring. >> - >> >> *If it=E2=80=99s a VM*, I=E2=80=99d provision a bit more capacity tha= n the current >> SQL Server allocation to give some headroom for tuning and unexpected >> overhead, and then right-size after observing the real load in Postgr= eSQL. >> >> Once the migration is done and in steady use, we can monitor CPU, memory= , >> and I/O in PostgreSQL and then optimise or scale down/up based on real >> metrics instead of guessing up front. >> >> >> Tayyab >> >> On Sun, Nov 30, 2025 at 11:14=E2=80=AFPM Laurenz Albe >> wrote: >> >>> On Mon, 2025-12-01 at 08:46 +0530, Raj wrote: >>> > I am migrating from MSSQL to POSTGRESQL. In MSSQL, I am using 64 vCPU >>> and 250GB RAM. >>> > Now how much we can give in postgres? >>> >>> If these specifications worked for you with Microsoft SQL Server, use >>> the same >>> with PostgreSQL. If you can, don't use Windows. >>> >>> Yours, >>> Laurenz Albe >>> >>> >>> --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000e258ba0644e5068b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

In the one Oracle -> Po= stgresql migration I did (where I came in after the AWS RDS Postgresql VMs = were already sped'ed=C2=A0and were 1:1 the same as the Oracle servers:<= /div>
- disk usage was 1/3 lower
- both CPU and RAM were 75% = over-specified.=C2=A0 (They could be chopped in half and performance would = still be good.)

But, of course, your mileage not o= nly might vary, but it will vary.

On Mon, Dec 1= , 2025 at 3:38=E2=80=AFAM Raj <rajeshkumar.dba09@gmail.com> wrote:
Sorry, it's Oracle t= o POSTGRESQL migration.=C2=A0

= I apologize for the confusion.

Please suggest based on Oracle.

On Mon, 1 Dec 2025, 14:00 Tayya= b Fayyaz, <= tayyab.humayl@gmail.com> wrote:
Hello Raj,

It really depends on how much of those 64 vCPUs and 250GB RA= M your SQL Server actually uses today, and whether you=E2=80=99re running o= n a physical box or a virtual machine.

PostgreSQL doesn=E2=80=99t have a 1:1 sizing formula against SQL Server.= I=E2=80=99d first look at real CPU/memory usage, workload pattern (OLTP vs= reporting), and how connections/queries behave. I=E2=80=99d also factor in= how well we can migrate and map the data types and queries, because good t= ype choices and query rewrites can significantly reduce resource usage.

  • If it=E2=80=99s a physical server, I=E2=80=99d start wi= th similar hardware for PostgreSQL and then tune Postgres parameters (share= d_buffers, work_mem, etc.) based on monitoring.

  • If it=E2=80=99s a VM, I=E2=80=99d provision a bit more = capacity than the current SQL Server allocation to give some headroom for t= uning and unexpected overhead, and then right-size after observing the real= load in PostgreSQL.

Once the migration is done and in steady use, we can monitor CPU, memory= , and I/O in PostgreSQL and then optimise or scale down/up based on real me= trics instead of guessing up front.



<= /div>
Tayyab

On Sun, Nov 3= 0, 2025 at 11:14=E2=80=AFPM Laurenz Albe <laurenz.albe@cybertec.at= > wrote:
= On Mon, 2025-12-01 at 08:46 +0530, Raj wrote:
> I am migrating from MSSQL to POSTGRESQL. In MSSQL, I am using 64 vCPU = and 250GB RAM.
> Now how much we can give in postgres?

If these specifications worked for you with Microsoft SQL Server, use the s= ame
with PostgreSQL.=C2=A0 If you can, don't use Windows.

Yours,
Laurenz Albe




--
Death to <Redacted>, and butter sauce.Don't boil me, I'm still alive.
<Redacted> lobs= ter!
--000000000000e258ba0644e5068b--