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 1vQWN5-00A16d-0l for pgsql-admin@arkaria.postgresql.org; Tue, 02 Dec 2025 19:49:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vQWN4-009nOJ-0M for pgsql-admin@arkaria.postgresql.org; Tue, 02 Dec 2025 19:49:10 +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.96) (envelope-from ) id 1vQWN3-009nOB-25 for pgsql-admin@lists.postgresql.org; Tue, 02 Dec 2025 19:49:10 +0000 Received: from mail-lj1-x22d.google.com ([2a00:1450:4864:20::22d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vQWN1-002nBq-2a for pgsql-admin@lists.postgresql.org; Tue, 02 Dec 2025 19:49:09 +0000 Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-37ba781a6c3so49818941fa.0 for ; Tue, 02 Dec 2025 11:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764704946; x=1765309746; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=N+RKBJFNhDEeYBH+vct5eeIXUu/Idon1/cAgIC5NDKM=; b=IJgV5+6i+Xk6DbPMaeWRGyiwhhmUm7j/LhV5hodZoiK3ywaHi72Z7TdpiDRe+zW5K1 6GovT6LHASlbvEolmIulkR/3EOniFTbYzvZPf7HiEu6oqMmcd6cDq+8lKBANi/jZi6BT 4zbqXlroI8gbce62MYdw7ghF682EEkIaKHhUxcHE/dQwIJADThsdr1Cwp0Lj8ILqxhS1 a0MojMbMjlaK05gd17YiixSGMU8k9cXiTGV0JNhoPeUkAsOShdqBq4JBDXjyo7sW0Wk1 BkGbNmXdZWADAJ7Ds4gY0UwOwDhy9KGO/ExkYD6rtcaKbepxGyVXq3qfH+/oXpaONhTp +lzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764704946; x=1765309746; h=cc: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=N+RKBJFNhDEeYBH+vct5eeIXUu/Idon1/cAgIC5NDKM=; b=aiSgVm6/pSkgtkHAJ33kUVsuC9LVEFl4skqVe0YnwFAnWe6fqLuJbF/nbua5LeNOKc HrTCpar9qH3+VA3MjHT4DNU00sdKeetGGSMABlkevdgfa63PlHzwvYXOtpH8BGxINxmM XFOKAj/BqF5S6MwqwITTpbjiIDv5CUrzfPpsWGARmdFBtf4pEG2r9gVyxFwi4x85Cyb8 4KQyKWiZqmP3w+1NAnYWNLVGxsCWa0JJ0cw3AgfCOweQpXrxKVwlAQ8+EomHttXt3Au8 Kazz9thsJdzYRyx2vR9grvuoOGZPO1oXAR9KZnGl7RCrFKAHQgGuWpK83ogK+uH3SPVH MzRQ== X-Gm-Message-State: AOJu0Yy21sVUkGa9IznI7ggJX739LgxJ8OGL5gz/FKysSZgw6WQVBzTo xXeg2IBHOSrOh8JVk2ZalKSfSXpW+zIKzo+X/BRVP6s1zgvwqk/8LlWovxcXQ9Hk0uR2WaWQXF7 4ARu+xM3nbmTdjDMDEnyInvQrGcYEQAU= X-Gm-Gg: ASbGncuUR+Uv91vQdqmzS5WIbFUN2WiOHNyryvsxAIWZkyRg9rOcPI+7pNLfDGDTMgt OLkSFk9+8pUu0rZ/VLAz6put9E5lebsh/FVbZnhsCW/+7sV6/p4NwBJti//k3medlL1ejDRG0CK jACFWESzfx90GLPdvOq5xQGJaUlBVsrnviM8UkvuVt7vtf0A4rupj9EwvMZH58leoRC+1byAqbh ciBArOiTR9h9lVX0VAj2wa6g89mGJ8l+jryDqXO4Acp2WcDt/9ofpyui3Mu/XVg9jwcftrztLmW KNT0mf1+89Aef6sLzIDWHVdAZx0fXQ== X-Google-Smtp-Source: AGHT+IF8Qa7mwePBbM1k+QJ+OQd+w9mPTi6rdXbSaC0Y9LIgx0kaRcF1ZjJxFgNWrIRSJ4mn0NihyCGc/ztsvdu6WiU= X-Received: by 2002:a2e:3e1a:0:b0:37b:9b58:dd0e with SMTP id 38308e7fff4ca-37e6153c50dmr1941181fa.10.1764704946203; Tue, 02 Dec 2025 11:49:06 -0800 (PST) MIME-Version: 1.0 References: <8db363787dc505e0dbe01ab48c437205928f1c2b.camel@cybertec.at> In-Reply-To: From: Raj Date: Wed, 3 Dec 2025 01:18:54 +0530 X-Gm-Features: AWmQ_bntFSo3qXR7bXAypynA7bizPd5-gsH3buM7o0toYeyTSjl0hZ8En50Qc14 Message-ID: Subject: Re: Migration from MSSQL to POSTGRESQL To: Ron Johnson Cc: Pgsql-admin Content-Type: multipart/alternative; boundary="00000000000073aff90644fd6384" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000073aff90644fd6384 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ron, it's On premises. Not cloud. On Mon, 1 Dec 2025, 20:15 Ron Johnson, wrote: > > In the one Oracle -> Postgresql migration I did (where I came in after th= e > 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 = wrote: > >> 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 phy= sical 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 reportin= g), >>> 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 a= nd >>> query rewrites can significantly reduce resource usage. >>> >>> - >>> >>> *If it=E2=80=99s a physical server*, I=E2=80=99d start with similar = hardware for >>> PostgreSQL and then tune Postgres parameters (shared_buffers, work_m= em, >>> etc.) based on monitoring. >>> - >>> >>> *If it=E2=80=99s a VM*, I=E2=80=99d provision a bit more capacity th= an the current >>> SQL Server allocation to give some headroom for tuning and unexpecte= d >>> overhead, and then right-size after observing the real load in Postg= reSQL. >>> >>> 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 vCP= U >>>> 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 >>>> >>>> >>>> > > -- > Death to , and butter sauce. > Don't boil me, I'm still alive. > lobster! > --00000000000073aff90644fd6384 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ron, it's On premises. Not cloud.

On Mon, 1 Dec 2025, 20:15 Ron Johnson, <ronljohnsonjr@gmail.com> wrote:

In the= one Oracle -> Postgresql 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:
- disk usage was 1/3 lower
- both C= PU and RAM were 75% over-specified.=C2=A0 (They could be chopped in half an= d 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 <rajeshkumar.dba09@gmail.com>= ; wrote:
Sorry, it's Oracle to POSTGRESQL migration.=C2=A0

I apologize for the confusion.

Please suggest based on Oracle.

On Mon, 1 Dec 2025, 14:00 Tayyab Fayyaz, <tayyab.humayl@gmail.c= om> wrote:
Hello Raj,

It rea= lly depends on how much of those 64 vCPUs and 250GB RAM your SQL Server act= ually uses today, and whether you=E2=80=99re running on 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!
--00000000000073aff90644fd6384--