You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/en/integrations/data-ingestion/clickpipes/postgres/faq.md
+43-2Lines changed: 43 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,13 +13,54 @@ If your ClickHouse Cloud service is idling, your Postgres CDC clickpipe will con
13
13
14
14
As an example, if your sync interval is set to 30 mins and your service idle time is set to 10 mins, Your service will wake-up every 30 mins and be active for 10 mins, then go back to idling.
15
15
16
-
17
16
### How are TOAST columns handled in ClickPipes for Postgres?
18
17
19
18
Please refer to the [Handling TOAST Columns](./toast) page for more information.
20
19
21
-
22
20
### How are generated columns handled in ClickPipes for Postgres?
23
21
24
22
Please refer to the [Postgres Generated Columns: Gotchas and Best Practices](./generated_columns) page for more information.
25
23
24
+
### Do tables need to have primary keys to be part of Postgres CDC?
25
+
26
+
Yes, for CDC, tables must have either a primary key or a [REPLICA IDENTITY](https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-REPLICA-IDENTITY). The REPLICA IDENTITY can be set to FULL or configured to use a unique index.
27
+
28
+
### Do you support partitioned tables as part of Postgres CDC?
29
+
30
+
Yes, partitioned tables are supported out of the box, as long as they have a PRIMARY KEY or REPLICA IDENTITY defined. The PRIMARY KEY and REPLICA IDENTITY must be present on both the parent table and its partitions. You can read more about it [here](https://blog.peerdb.io/real-time-change-data-capture-for-postgres-partitioned-tables).
31
+
32
+
### Can I connect Postgres databases that don't have a public IP or are in private networks?
33
+
34
+
Yes! ClickPipes for Postgres offers two ways to connect to databases in private networks:
35
+
36
+
1.**SSH Tunneling**
37
+
- Works well for most use cases
38
+
- See the setup instructions [here](https://clickhouse.com/docs/en/integrations/clickpipes/postgres#adding-your-source-postgres-database-connection)
39
+
- Works across all regions
40
+
41
+
2.**AWS PrivateLink**
42
+
- Available in three AWS regions:
43
+
- us-east-1
44
+
- us-east-2
45
+
- eu-central-1
46
+
- For detailed setup instructions, see our [PrivateLink documentation](https://clickhouse.com/docs/knowledgebase/aws-privatelink-setup-for-clickpipes#requirements)
47
+
- For regions where PrivateLink is not available, please use SSH tunneling
48
+
49
+
### How do you handle UPDATEs and DELETEs?
50
+
51
+
ClickPipes for Postgres captures both INSERTs and UPDATEs from Postgres as new rows with different versions (using the _peerdb_version column) in ClickHouse. The ReplacingMergeTree table engine periodically performs deduplication in the background based on the ordering key (ORDER BY columns), retaining only the row with the latest _peerdb_version.
52
+
53
+
DELETEs from Postgres are propagated as new rows marked as deleted (using the _peerdb_is_deleted column). Since the deduplication process is asynchronous, you might temporarily see duplicates. To address this, you need to handle deduplication at the query layer.
54
+
55
+
For more details, refer to:
56
+
57
+
*[ReplacingMergeTree table engine best practices](https://docs.peerdb.io/bestpractices/clickhouse_datamodeling#replacingmergetree-table-engine)
Please refer to the [ClickPipes for Postgres: Schema Changes Propagation Support](./schema-changes) page for more information.
63
+
64
+
### What are the costs for ClickPipes for Postgres CDC?
65
+
66
+
During the preview, ClickPipes is free of cost. Post-GA, pricing is still to be determined. The goal is to make the pricing reasonable and highly competitive compared to external ETL tools.
ClickPipes for Postgres can detect schema changes in the source tables. It can propagate some of these changes to the corresponding destination tables as well. The way each schema change is handled is documented below:
| Adding a new column (`ALTER TABLE ADD COLUMN ...`) | Propagated automatically, all rows after the change will have all columns filled |
11
+
| Adding a new column with a default value (`ALTER TABLE ADD COLUMN ... DEFAULT ...`) | Propagated automatically, all rows after the change will have all columns filled but existing rows will not show the DEFAULT value without a full table refresh |
12
+
| Dropping an existing column (`ALTER TABLE DROP COLUMN ...`) | Detected, but not propagated. All rows after the change will have NULL for the dropped columns |
0 commit comments