Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oDReg-0003Lj-H7 for pgsql-performance@arkaria.postgresql.org; Mon, 18 Jul 2022 14:23:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oDRed-0002cr-Mh for pgsql-performance@arkaria.postgresql.org; Mon, 18 Jul 2022 14:23:23 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oDRed-0002ci-3O for pgsql-performance@lists.postgresql.org; Mon, 18 Jul 2022 14:23:23 +0000 Received: from campbell-lange.net ([178.79.140.51]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oDReW-0000ZN-Ap for pgsql-performance@lists.postgresql.org; Mon, 18 Jul 2022 14:23:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=campbell-lange.net; s=it; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rnAusxgHdklm257z5YrkUHTFZWIEUyOvpRyS4eqiO/s=; b=ntc2JG7FOILTNqpnPf5dieU1h4 8B/7blMujuYbYF2RwjW2KPT5qYPWMmjgnEeOrvvGWWipElFRgdI3Mlk6hwA3UCRCHzeEFeFr9Bd10 XnTsUePdmcOmgYeURb7WApYvyXhrUksmzjQmdiWEXYU05jVM2F5bmELn6MH+V/iqk5Mg=; Received: from arennes-556-1-251-68.w2-14.abo.wanadoo.fr ([2.14.250.68] helo=rory-t470s) by campbell-lange.net with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1oDReU-005Tcj-BJ; Mon, 18 Jul 2022 14:23:14 +0000 Received: from rory by rory-t470s with local (Exim 4.94.2) (envelope-from ) id 1oDReT-00182f-DM; Mon, 18 Jul 2022 15:23:13 +0100 Date: Mon, 18 Jul 2022 15:23:13 +0100 From: Rory Campbell-Lange To: Rick Otten Cc: Pgsql Performance Subject: Re: data consolidation: logical replication design considerations Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 17/07/22, Rick Otten (rottenwindfish@gmail.com) wrote: > On Sat, Jul 16, 2022 at 12:07 PM Rory Campbell-Lange < > rory@campbell-lange.net> wrote: > > > I'd be grateful for some comments on the advisability of using a large > > number of concurrent logical replication publications/subscriptions. > > Below I've set out the current environment and a suggested design. > > Apologies for the length of this email. > > Another possibility is to use SymmetricDS for this. [ > https://symmetricds.org ] SymmetricDS was originally developed to keep > databases on thousands of Point-of-Sale databases (in cash registers) in > sync with pricing and inventory data for large international retailers. > > There are lots of other use cases, but even 10-12 years ago it was scalable > to the extent you are describing you need here. > > The main drawback is that it is trigger based, so there is some slight > latency introduced for insert/update/delete actions on the tables on the > appropriate master, but it usually isn't significant. Thanks very much for the pointer to SymmetricDS. I haven't come across it before. The architecture, configuration and use look very straightforward, although using java would be new to our production environment, and SymmetricDS doesn't seem to be in Debian. I'd be grateful to know if 500 odd publishers/subscribers is "out of the park" or reasonable for a reasonably powerful machine (as described in my original email). I would have thought using the native logical replication capabilities would be much more scalable and efficient than stepping outside of postgresql. Regards, Rory