Lessons From a Year of Postgres Cdc in Production
Posted18 days agoActive11 days ago
clickhouse.comTech Discussionstory
informativepositive
Debate
20/100
Postgres CdcClickhouseData_storage
Key topics
Postgres Cdc
Clickhouse
Data_storage
Discussion Activity
Moderate engagementFirst comment
6d
Peak period
6
156-168h
Avg / period
4
Key moments
- 01Story posted
Dec 19, 2025 at 8:00 PM EST
18 days ago
Step 01 - 02First comment
Dec 26, 2025 at 6:09 AM EST
6d after posting
Step 02 - 03Peak activity
6 comments in 156-168h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 26, 2025 at 7:42 PM EST
11 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 46332784Type: storyLast synced: 12/26/2025, 4:10:36 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
> "Here goes the Open Source reference to our validation logic."
> "PeerDB Open Source Repository"
I hate to be that guy, but PeerDB seems to be governed by the Elastic License [1] which makes it NOT open source.
The difference is not small, but significant for many. For one, it won't get integrated into other OSS projects.
In my particular case, we have integrated Debezium Embedded into StackGres, as a high level object (CRD) named SGStream [2]. It allows Postgres logical replication from Postgres and exports to another Postgres and/or CloudEvents. No Kafka required. We'd love to consider other alternatives like PeerDB, but not being OSS is a red line we can't cross (having said that, we're really happy with Debezium in general, but having competition and alternatives it's always great).
[1]: https://github.com/PeerDB-io/peerdb/blob/main/LICENSE.md
[2]: https://stackgres.io/doc/latest/reference/crd/sgstream/#sgst...
[edit: formatting]
The wording in that post was an unintentional miss on my part. Apologies for that. We’ve just fixed it. Thanks for flagging it!
To add some context, PeerDB was originally released under ELv2 well before the acquisition. During the acquisition we made a choice to keep the project as-is rather than change its license, so this wasn’t a new decision made at that time — just continuity with how the project already existed.
We appreciate the feedback, around integration and downstream OSS adoption. That overall makes sense. We’ll take it into account as we think about licensing going forward.
I'd love to test and compare PeerDB with Debezium (Embedded), and even SynchDB. But as said, the licensing is a blocker for us. And given the focus and bandwidth we currently have, we won't have the chance to deeply look at it unless there's a high chance we could integrate it into StackGres.
Anyway feel free to DM me if you'd like to talk more.
I wonder if that's intended by Postgres? Doesn't seem logical at first glance.
There may be room for improvement in PostgreSQL, by persisting this state to help these reconnections, but I think this is non-trivial and complex than I think, because of the guarantees PostgreSQL must provide around correctness, consistency and reliability. I’ll let PostgreSQL committers/contributors chime in too on this for a more precise analysis.
Also, based on what I’ve read, physical replication does not have this issue because it directly ships WAL files (instead of contructing a txn) and reconstructs state on the standby.