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 1uFRn4-004Vqj-Qv for pgsql-general@arkaria.postgresql.org; Thu, 15 May 2025 06:09:59 +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 1uFRn2-00CRmJ-VP for pgsql-general@arkaria.postgresql.org; Thu, 15 May 2025 06:09:56 +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 1uFRn2-00CRmB-KX for pgsql-general@lists.postgresql.org; Thu, 15 May 2025 06:09:56 +0000 Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uFRmz-001yvN-2c for pgsql-general@lists.postgresql.org; Thu, 15 May 2025 06:09:56 +0000 Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-acb39c45b4eso80209966b.1 for ; Wed, 14 May 2025 23:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747289392; x=1747894192; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=wpQ82+0bqOzzu5NMW1cyb73C76RqOnt8SN1v1f6Ssog=; b=gVp7/x4eZbzgTlp+prbUGs0rpt9O0LUWiacgOOsG2JoTZ673ETgLatrx0RhT28nYpb P1P4jaxjHPOtl4eOMOwCnKE0pdPltZAYIrWLttEGYXq/pGW7OUzqdWHSJYdlXsN0u9s3 iPGGMpDPQHanldOOo2waKqi6tAhZAMwXMZL/8Q+eyKEqRXa4aIUz49KnSz9ov+WWRQe/ sfFcRyhvBJE+ENqGdcy3h/qy2aW1aFt16n/M3o7VJ3IlOVAN21HXPhwWE4ATEhigHGqg 3iPCjMIy+bp4iwWx/pd+PFdSl48ouxMjoyEamUu0IdxdEN40n7vPiRbcU1o1toii48sl Kkjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747289392; x=1747894192; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=wpQ82+0bqOzzu5NMW1cyb73C76RqOnt8SN1v1f6Ssog=; b=LV4YMk0YoLvT7I+OHnd558Zl4I0oqiFJ1zMKqYWELBLB5iCt+RXmIuaBdUIRogoTN0 hmJsnJlfd6oIGCj3WPwHw6bKo8Dl9+23YjdrR2H/e4vtSKCY258xwt9EnVyjTGPfK3I5 Qh2bZuFcve0b30m/BcOFLvElFbT+ggjKUef8bXNldOb8MZ9o2Rzn1QyHFFmS6itGc5v3 H+SEQyeemCMTKDeWFh0g4KY/vXkg9W7qVEnNJT1MXFIUNV7oRxJyaBoBvNId+AgrS7i7 KjF5BdAh8gHHP8qfx/24C4fw6Nm7+Ff054u0Zz8L+olYeboy8qeQ7LzOVnGfs33mRSYW 01rg== X-Gm-Message-State: AOJu0YzFHx5A+fh50eO7wmNN/e2rGuJsY8aM0FeZEvF37abBVsTkJdWz QkJT00Ib1ZvyS+O29xegwR8/2PKrtxU+sdSAzV9f7ynZJLlCBquI8tpqd/mctJi+yWxqjJcifyv aVFpyMh748X1BXT40CcCL7RHXOe2zVueP X-Gm-Gg: ASbGncs5d+q1F+x2aTCQsEuFnt85wxjGN/x7h+ae5f1P5o4P25d2mZ8QBArupPMpB3j c50udq9LQYMb9n+hjugpch2OW2XiOduuIc9IXWKn2LdGbp971WPe5qH6nkXBb8HXwoYpcT/7T0b CBpeQRH6URhAjl5T3jPeZ1LrO+FdZgi2OkIPYvG58c6gvSl3WOjMPi76TEoo2cD8f8w5A= X-Google-Smtp-Source: AGHT+IEei0yr7WQFmYF3r5XcMtRfHxp5H7gXsf79DWUjpP6HX0J+AYmOqEydiwgiPeUlOJeIwwAWwDnUVemznhCQ24g= X-Received: by 2002:a17:907:8749:b0:ad2:55e4:454e with SMTP id a640c23a62f3a-ad4f74d5bffmr572455366b.58.1747289391970; Wed, 14 May 2025 23:09:51 -0700 (PDT) MIME-Version: 1.0 From: veem v Date: Thu, 15 May 2025 11:39:39 +0530 X-Gm-Features: AX0GCFucO68gxcN_P9YrHv8FcQtC2YYhYunciJsPhqaamSm-fjEmldCm_2vH-7k Message-ID: Subject: How to have a smooth migration To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000873e7b063526836a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000873e7b063526836a Content-Type: text/plain; charset="UTF-8" Hi, Its postgres database behind the scenes. We have a use case in which the customer is planning to migrate data from an older version (V1) to a newer version (V2). For V2, the tables will be new, but their structure will be similar to the V1 version with few changes in relationship might be there. We want to have this migration approach happen in multiple phases in which each time the delta data from version V1 will be moved to version- V2 and then final cutover will happen to V2 if all looks good or else rollback to V1. The tables are smaller in size like max ~100K records in tables. My question is, is it a good idea to have an approach in which we will have procedures created to move the delta data in every phase and schedule those using some tasks for each table. Or any other strategy should we follow? Also another thing to note , we have used sequences as primary keys in some tables and they have FK relationships with other tables, so the same sequence number in version V2 will cause issues/conflict, so how should we handle this scenario? Should we just create new sequences with higher start values? Regards Veem --000000000000873e7b063526836a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
Its postgres database behind the scenes.

We = have a use case in which the customer is planning to migrate data from an o= lder version (V1) to a newer version (V2). For V2, the tables will be new, = but their structure will be similar to the V1 version with few changes in r= elationship might be there. We want to have this migration approach happen = in multiple phases in which each time the delta data from version V1 will b= e moved to version- V2 and then final cutover will =C2=A0happen to V2 if al= l looks good or else rollback to V1. The tables are smaller in size like ma= x ~100K records in tables.

My question is, is it a good idea to have= an approach in which we will have procedures created to move the delta dat= a in every phase and schedule those using some tasks for each table. Or any= other strategy should we follow?

Also another thing to note , we h= ave used sequences as primary keys in some tables and they have FK relation= ships with other tables, so the same sequence number in version V2 will cau= se issues/conflict, so how should we handle this scenario? Should we just c= reate new sequences with higher start values?

Regard= s
Veem
--000000000000873e7b063526836a--