public inbox for [email protected]
help / color / mirror / Atom feedFrom: Raj <[email protected]>
To: Ron Johnson <[email protected]>
Cc: Pgsql-admin <[email protected]>
Subject: Re: Migration from MSSQL to POSTGRESQL
Date: Wed, 3 Dec 2025 01:18:54 +0530
Message-ID: <CAJk5AtYpXAqiY9SvhVw2EVZGBOSPocvouyWVOOX1ZXuYf4A7yA@mail.gmail.com> (raw)
In-Reply-To: <CANzqJaCyt9HUa1jG0Lx_zY+Wmw0bX-O9kKWtHe3p-1JcBCOoZQ@mail.gmail.com>
References: <CAJk5AtY9E2E3tL3=1zt82LBZK7Q8BkH65BNG=43oa3qWLrPAtg@mail.gmail.com>
<[email protected]>
<CAFVRaQ2zxmVY+zqADEv2hqo9uR6Q-iYn0v2MQ2EKUtv+yRZKsA@mail.gmail.com>
<CAJk5AtYYmxWH6Tbp-3dAiMKd3Ynu4J6ajtOc48rKsa1s3Kk0SA@mail.gmail.com>
<CANzqJaCyt9HUa1jG0Lx_zY+Wmw0bX-O9kKWtHe3p-1JcBCOoZQ@mail.gmail.com>
Hi Ron, it's On premises. Not cloud.
On Mon, 1 Dec 2025, 20:15 Ron Johnson, <[email protected]> wrote:
>
> 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 AM Raj <[email protected]> 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, <[email protected]> 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’re running on a physical box or
>>> a virtual machine.
>>>
>>> PostgreSQL doesn’t have a 1:1 sizing formula against SQL Server. I’d
>>> first look at real CPU/memory usage, workload pattern (OLTP vs reporting),
>>> and how connections/queries behave. I’d also factor in how well we can
>>> migrate and map the data types and queries, because good type choices and
>>> query rewrites can significantly reduce resource usage.
>>>
>>> -
>>>
>>> *If it’s a physical server*, I’d start with similar hardware for
>>> PostgreSQL and then tune Postgres parameters (shared_buffers, work_mem,
>>> etc.) based on monitoring.
>>> -
>>>
>>> *If it’s a VM*, I’d provision a bit more capacity than the current
>>> SQL Server allocation to give some headroom for tuning 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 metrics instead of guessing up front.
>>>
>>>
>>> Tayyab
>>>
>>> On Sun, Nov 30, 2025 at 11:14 PM Laurenz Albe <[email protected]>
>>> 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
>>>>
>>>>
>>>>
>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!
>
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Migration from MSSQL to POSTGRESQL
In-Reply-To: <CAJk5AtYpXAqiY9SvhVw2EVZGBOSPocvouyWVOOX1ZXuYf4A7yA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox