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 1v9qx5-009bw7-2e for pgsql-admin@arkaria.postgresql.org; Fri, 17 Oct 2025 20:21:26 +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 1v9qx3-0055TB-KN for pgsql-admin@arkaria.postgresql.org; Fri, 17 Oct 2025 20:21:24 +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 1v9qx3-0055T3-2M for pgsql-admin@lists.postgresql.org; Fri, 17 Oct 2025 20:21:24 +0000 Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v9qwz-002mOw-1D for pgsql-admin@lists.postgresql.org; Fri, 17 Oct 2025 20:21:23 +0000 Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-61a54560c1fso466902a12.0 for ; Fri, 17 Oct 2025 13:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bisoft-com-tr.20230601.gappssmtp.com; s=20230601; t=1760732480; x=1761337280; 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=r5y6yRKxf0tBz2n9ctasd9ELO+u9jcQHDE3HXUlEFfs=; b=FuafPp/uxK16wVMNnWmrtiauiMXYjGICURYkWoFzIRsB3/Q1XnUu81DIwHesAna3bo Uu0KvVmuVt52m7oL6z91kZPIRY8Bp7V7sr4PK3xf1DmnMG6I77Wk26r9I55hodjTRK8l QS6I98Ac58uPU/r7ezYjl8/8EJ708ogZsmhdHgJMyJcS/aofz3GEnsShdI3+qMIKpbTZ 7RZ4FdqXnFgeMzI4OhhHXLJrzodfmr1wzx22GpX590fyQ7QuFXyeQYQmY6bURrd0AIt1 bCEQP1l6nq7aI1b2tvUkRFsgnvK+349WqRjbShxNjMjij57jX0oOM6tpMRGMwkDzKJQ5 OOYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760732480; x=1761337280; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=r5y6yRKxf0tBz2n9ctasd9ELO+u9jcQHDE3HXUlEFfs=; b=PQ4mSzJbZX8LQrwIWKZtajezrTu5XGK2BHTq5elWBDF6n25BREjlmmMbJXMZCN9oud fSDfOnYBMbbuLu5iHp36ZfAbEeGcp7r7O8GP8lwQ/+U8Fv4Dun7TCPEfVlFippdW62qi uXW5YbUeTTQKxnGwWvwFbYdEfIuNCX0TGnyaNQZGjkvDzzOt0XkDUXvB91CzxTXFEByO M0qOiNkCQVd4A8/DAA7IPf6g+o1OKX+OpaU2gc8d1lIrxfWSJu/90TJmNtY8ChNeEVBA xWBmfW4rCkHpM0L8r8SAC2JDi32Ay6Y4kiSkfxV7yjTado3bcsd1Ba3uaW4lNiLRUUJf GB2Q== X-Forwarded-Encrypted: i=1; AJvYcCUxAjfGUg9uwdUB3mF0pi0YZAOWsQ2tSB12P/IyPmb7nUmCs34MIbiMj8N+S7Ks/MODMhtRFWEQAbreMw==@lists.postgresql.org X-Gm-Message-State: AOJu0YyPMJ6By/ylHCHnc8n0QWSYt8xehXoseCqtUAgnmO8j3wg4/ARX gr64Y0Kxca26b5zMplkv/erMZ3mHJzQXpnluAAE/PE3Hc563bBfPh4crL5e5QZ9L877LH+wevHS prS5yOWfiSI7O2c/niih8hcql0Z4YYoPllL+zymYzpw== X-Gm-Gg: ASbGncvxgy/TEHevwST41WJgVpAQ3gAsO8KeOLPNq7UWF7KDRlaj8RjNeBSLuNuYCyq CUk3rRNpNYY0aL4v3NqqA//FkYOe+n8/qOlLqcppwlmptajTJ54bMB1B6ZyFUVQ54ZSNWlItg0u zumQHvgz7ggzVz/RQCej5ixkAq5ntBnOEq7oy0YqECP8UkjAAd7fphIaMJ+1sDfmkEKOTDWCJN+ pdqjYoGH8C3VPD6ddtoSZBDRZ1UEGbPt7mxsBwo+Lj+w38CWQEBiIcgmoA= X-Google-Smtp-Source: AGHT+IE67ENY41XWl40LBD8BUCTfvlbkdTMKryR0RxhcuMdtJGpKFxtbxHX8eGTVfAw8EkOnX3tb+tZ9ctlytIrDMqw= X-Received: by 2002:a05:6402:26c9:b0:637:ef27:c672 with SMTP id 4fb4d7f45d1cf-63c1f6d2a65mr2561348a12.6.1760732479686; Fri, 17 Oct 2025 13:21:19 -0700 (PDT) MIME-Version: 1.0 References: <1915052734.3603827.1760618757611@mail.yahoo.com> In-Reply-To: From: =?UTF-8?Q?Muhammet_Kurto=C4=9Flu?= Date: Fri, 17 Oct 2025 23:21:06 +0300 X-Gm-Features: AS18NWD8ujUKSDIcm7gui3sC5zRH9_ROSyBZhWmrL8vlhVEmsPmhePosdcErh50 Message-ID: Subject: Re: Guidance Requested: Migrating Large-Scale DB2 Databases to PostgreSQL To: mahamood hussain Cc: Brian Crockard , Pgsql-admin Content-Type: multipart/alternative; boundary="000000000000ff1ae4064160790a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ff1ae4064160790a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Open source Symetricds support bidirectonal replication from db2 to postgresql you can look at below. https://symmetricds.org/connectors/ There are open source topla such as pmm , graphana etc to monitor performance of postgresql . =C4=B0 recommend to take professional support for postgresql and open sourc= e technologies for migration. No need o take edb support. There are lots of company that gives postgresql professional supports with required sla. https://www.postgresql.org/support/professional_support/ One of them is our company BiSoft located in TURKEY www.bisoft.com.tr *Muhammet KURTO=C4=9ELU* T: +90(312) 220 12 20 <%2B90%28374%29%20262%2098%2000> F: +90(312) 286 00 10 <%2B90%28374%29%20262%2090%2091> muhammet.kurtoglu@bisoft.com.tr 17 Eki 2025 Cum, saat 22:49 tarihinde mahamood hussain < hussain.ieg@gmail.com> =C5=9Funu yazd=C4=B1: > Hi Brian, Ron, Kurtoglu, > > Thank you all for the thoughtful responses. It took a bit of effort to > pull this information together, but I'm glad to see the insights coming i= n > =E2=80=94 it's given me more confidence that this migration is indeed ach= ievable > with the right approach. > > To clarify our setup: > We're currently running DB2 LUW v11.5.9 (Advanced Enterprise Server > Edition). One of our key concerns is licensing cost, which is driving our > move to PostgreSQL. > A few follow-up questions based on your responses: > > 1. > > InfoSphere Data Replication (CDC): > We understand this is a strong option, but it likely incurs additional > licensing costs. We=E2=80=99re exploring Fivetran for data replication= between DB2 > and PostgreSQL, with the flexibility to fall back to DB2 if performanc= e or > stability issues arise in production. > - > > Can CDC be used for such a failback scenario (i.e., from PostgreSQL > =E2=86=92 DB2) similar to how Fivetran supports bidirectional sync? > 2. > > Open-source Tools: > Do we have any robust open-source tools that support both forward and > backward replication between DB2 and PostgreSQL? This would help us pl= an > for both migration and rollback scenarios without heavy vendor lock-in= . > 3. > > Pitfalls to Avoid During Migration: > Since our primary goal is cost reduction, we would ideally avoid > needing to fall back to DB2. Based on your experience, what are some c= ommon > pitfalls or gotchas we should look out for when moving from DB2 to > PostgreSQL? > 4. > > PostgreSQL Performance Tuning & Config: > If there=E2=80=99s a list of standard PostgreSQL parameters that you'= d > recommend tweaking right after installation =E2=80=94 especially for l= arge datasets > =E2=80=94 that would be very helpful. We're anticipating around 100+ c= oncurrent > connections during peak hours and migrating some very large tables (up= to > 80B rows). > 5. > > Community vs Enterprise Support: > In production, having support with a guaranteed response time (e.g., > under an hour) is crucial. > - > > Does the PostgreSQL community offer any premium or paid support > options with SLAs, or would we need to go with providers like EDB f= or this > level of assurance? > > ------------------------------ > > > On Thu, Oct 16, 2025 at 6:15=E2=80=AFPM Brian Crockard > wrote: > >> You may want to look into an IBM product called InfoSphere Data >> Replciation (CDC) >> >> >> https://www.ibm.com/docs/nl/idr/11.4.0?topic=3Drequirements-supported-so= urce-targets >> >> It will replicate data from DB2 to PostgreSQL. You can set it up to >> actively replciate the data and keep it consistent. Then perform a cutov= er >> at some point to the new system running against the new replicated >> database. You will then have all of your historical data in the new syst= em. >> We used this on an extremely active system and it hard very few issues. >> >> On Wednesday, October 15, 2025 at 05:15:00 PM EDT, mahamood hussain < >> hussain.ieg@gmail.com> wrote: >> >> >> Hi Team, >> >> We are in the process of migrating several DB2 databases to PostgreSQL, >> primarily to reduce the high licensing costs associated with DB2. These >> databases support retail applications (e.g., supermarkets and stores), a= nd >> during peak hours, we anticipate over 100 concurrent connections. >> ------------------------------ >> Current Database Profile: >> >> - >> >> Approximately 3,000 tables in total >> - >> >> Around 100 tables contain active data >> - >> >> Most tables have low data volume >> - >> >> A few large tables range from 10 GB to 2 TB >> - >> >> The largest table contains approximately 80 billion rows >> >> ------------------------------ >> Migration Approach: >> >> - >> >> We are using Ispirer for code conversion (DB2 to PostgreSQL). >> - >> >> For data migration, we are evaluating Fivetran, but noted that it >> relies on the COPY method for data loading. >> >> ------------------------------ >> Questions & Areas Where We Need Guidance: >> >> 1. >> >> Is Fivetran a suitable option for migrating very large datasets >> (e.g., tables with 80+ billion rows)? >> 2. >> >> Are there any reliable open-source tools for DB2 to PostgreSQL data >> migration that we can use internally, without needing to invest in a = tool >> like Fivetran? >> 3. >> >> Are there more scalable or efficient alternatives for both the >> initial load and ongoing/incremental sync to PostgreSQL? >> >> ------------------------------ >> Additional Input Requested: >> >> - >> >> What are the key best practices (Do=E2=80=99s and Don=E2=80=99ts) to = keep in mind >> during a large-scale DB2 =E2=86=92 PostgreSQL migration? >> - >> >> Are there specific PostgreSQL settings or configurations we should >> pay attention to for optimizing performance, especially for large dat= asets >> and DB2-style workloads? >> >> ------------------------------ >> >> We are keen to ensure performance, data integrity, and scalability >> throughout this migration. Any insights=E2=80=94particularly from those = with >> experience in similar large-scale PostgreSQL implementations=E2=80=94wou= ld be >> highly appreciated. >> >> If this is not the right forum for these questions, please do let me kno= w >> if there is a better place to seek this guidance. >> >> Thanks in advance for your support! >> > --000000000000ff1ae4064160790a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi
Open source Symetricds su= pport bidirectonal replication from db2 to postgresql you can look at below= .=C2=A0
https://symmetricds.org/connectors/=C2=A0<= /div>

There are open source topla such as pmm , = graphana etc to monitor performance of postgresql .
= =C4=B0 recommend to take professional support for postgresql and open sourc= e technologies for migration.

No need o take edb support. There are lots of company that gives post= gresql professional supports with required sla.

=
One of them is our company BiSo= ft located in TURKEY
www.bisoft.com.tr
=

Muhammet KURTO=C4=9ELU

T:=C2=A0=C2=A0+90(312) 220 12 20

F:=C2=A0=C2=A0+90(312) 286 00 10=

muhammet.kurtoglu@bisoft.com.tr<= /a>=C2=A0

=C2=A0=C2=A0=C2= =A0=C2=A0







17 Eki 2025 Cum, saat 22:49 tarihin= de mahamood hussain <hussain.ie= g@gmail.com> =C5=9Funu yazd=C4=B1:

Hi Brian, Ron, Kurtoglu,

Thank you all for the thoughtful responses. It took a bit of effort to p= ull this information together, but I'm glad to see the insights coming = in =E2=80=94 it's given me more confidence that this migration is indee= d achievable with the right approach.

To clarify our setup:
We're currently running DB2 LUW v11.5.9 (Advanced Enterprise Server Edi= tion). One of our key concerns is licensing cost, which is driving our move= to PostgreSQL.

A few follow-up questions based on y= our responses:

  1. InfoSphere Data Replication (CDC):
    We understand this is a strong option, but it likely incurs additional lice= nsing costs. We=E2=80=99re exploring Fivetran for data replication between = DB2 and PostgreSQL, with the flexibility to fall back to DB2 if performance= or stability issues arise in production.

    • Can CDC be used for such a failback scenario (i.e., from PostgreSQL =E2= =86=92 DB2) similar to how Fivetran supports bidirectional sync?

  2. Open-source Tools:
    Do we have any robust open-source tools =C2=A0that support both forward and= backward replication between DB2 and PostgreSQL? This would help us plan f= or both migration and rollback scenarios without heavy vendor lock-in.

  3. Pitfalls to Avoid During Migration:
    Since our primary goal is cost reduction, we would ideally avoid needing to= fall back to DB2. Based on your experience, what are some common pitfalls = or gotchas we should look out for when moving from DB2 to PostgreSQL?

  4. PostgreSQL Performance Tuning & Config:
    If there=E2=80=99s a list of standard PostgreSQL parameters =C2=A0that you&= #39;d recommend tweaking right after installation =E2=80=94 especially for = large datasets =E2=80=94 that would be very helpful. We're anticipating= around 100+ concurrent connections during peak hours and migrating some ve= ry large tables (up to 80B rows).

  5. Community vs Enterprise Support:
    In production, having support with a guaranteed response time (e.g., under = an hour) is crucial.

    • Does the PostgreSQL community offer any premium or paid support options = with SLAs, or would we need to go with providers like EDB for this level of= assurance?


On Thu, Oct 16, 2025 at 6:15=E2=80=AFPM= Brian Crockard <bcrockard@yahoo.com> wrote:
You may want to look into an IBM product called I= nfoSphere Data Replciation (CDC)


It will replicate= data from DB2 to PostgreSQL. You can set it up to actively replciate the d= ata and keep it consistent. Then perform a cutover at some point to the new= system running against the new replicated database. You will then have all= of your historical data in the new system. We used this on an extremely ac= tive system and it hard very few issues.=C2=A0

=20
=20
On Wednesday, October 15, 2025 at 05:15:00 PM EDT, maha= mood hussain <

Hi Team,

We are in the process of migrating several DB= 2 databases to PostgreSQL, primarily to reduce the high licensing costs ass= ociated with DB2. These databases support retail applications (e.g., superm= arkets and stores), and during peak hours, we anticipate over 100 concurren= t connections.

Current Database Prof= ile:

  • Approximately 3,000 tables in total

  • Around 100 tables contain active data

  • Most tables have low data volume

  • A few large tables range from 10 GB to 2 TB

  • The largest table contains approximately 80 billion rows

Migration Approach:

We are using Ispirer for code conversion (DB2 to PostgreSQL).

  • For data migration, we are evaluating Fivetran, but noted that it relie= s on the COPY method for data = loading.

    • Questions & Areas Where We Nee= d Guidance:

    1. Is Fivetran a suitable option for migrating very large datasets (e.g., = tables with 80+ billion rows)?

    2. Are there any reliable open-source tools for DB2 to PostgreSQL data mig= ration that we can use internally, without needing to invest in a tool like= Fivetran?

    3. Are there more scalable or efficient alternatives for both the initial = load and ongoing/incremental sync to PostgreSQL?

    Additional Input Requested:=

    • What are the key best practices (Do=E2=80=99s and Don=E2=80=99ts) to ke= ep in mind during a large-scale DB2 =E2=86=92 PostgreSQL migration?

    • Are there specific PostgreSQL settings or configurations we should pay = attention to for optimizing performance, especially for large datasets and = DB2-style workloads?

    We are keen to ensure performance, data integrity, and scalab= ility throughout this migration. Any insights=E2=80=94particularly from tho= se with experience in similar large-scale PostgreSQL implementations=E2=80= =94would be highly appreciated.

    If this is not the right forum for t= hese questions, please do let me know if there is a better place to seek th= is guidance.

    Thanks in advance for your support!

    --000000000000ff1ae4064160790a--