Is logical replication using pglogical possible with timescaleDB?
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
In this article, we will explore the possibility of using logical replication with TimescaleDB through pglogical. Logical replication enables you to replicate data changes selectively from one database to another, allowing for diverse topologies and use cases beyond simple data redundancy. pglogical is one of the popular extensions for PostgreSQL to achieve logical replication. We'll examine how this can be configured with TimescaleDB, which is an extension of PostgreSQL optimized for time-series data.
Understanding TimescaleDB
TimescaleDB is an open-source database designed for time-series data, enabling efficient querying, insertion, and data retention features. By leveraging the underlying PostgreSQL architecture, it adds additional capabilities through custom hypertables to handle large-scale time-series datasets.
Introduction to pglogical
pglogical provides powerful logical replication capabilities for PostgreSQL databases. Unlike physical replication, logical replication allows for:
- Selective table replication.
- Version upgrades with minimal downtime.
- Diverse topologies such as multi-source, downstream replicas, etc.
pglogical achieves this by using WAL (Write-Ahead Log) decoding to transform the database changes into logical changesets that can be applied at the destination.
Configuring pglogical with TimescaleDB
To enable logical replication between two TimescaleDB instances using pglogical, follow these steps:
Prerequisites
- PostgreSQL 9.4 or later, with TimescaleDB installed.
- pglogical extension installed on both source and target databases.
- Network connectivity between the source and target instances.
Steps to Set Up pglogical Replication
1. Enable Required Extensions
First, ensure that the pglogical and TimescaleDB extensions are enabled on both the source and destination databases:
2. Configure the Source Database
On the source database, set up a provider node:
3. Add Replication Set
Define which tables or sets of tables should be replicated. With TimescaleDB, you might want to replicate specific hypertables or continuous aggregates:
4. Configure the Destination Database
On the target database, set up a subscriber node:
5. Create Subscription
Finally, create a subscription from the subscriber_node to consume changes from the provider_node:
With these steps, logical replication should be configured. Data changes on the source tables will propagate to the destination.
Key Considerations
- Compatibility: Ensure that the PostgreSQL versions and TimescaleDB versions are compatible to avoid replication conflicts.
- Data Integrity: Logical replication can sometimes lead to conflicts if concurrent changes occur at multiple nodes.
- Performance: Logical replication emphasizes high performance, but the replication overhead can impact write-heavy workloads.
- Monitoring: Proper monitoring setup is essential to detect replication lags or failures.
Summary Table
| Feature | TimescaleDB + pglogical |
| Replication Type | Logical |
| Replication Granularity | Table-level (Supports Hypertables) |
| Downtime | Minimal (during setup) |
| Use Cases | Cross-region replicas, Schema changes, etc. |
| Dependency | PostgreSQL-compatible versions |
Conclusion
Logical replication using pglogical is indeed feasible with TimescaleDB, enabling flexible replication topologies along with robust time-series management. Whether it's for ensuring high availability, real-time analytics, or seamless updates between environments, harnessing logical replication can significantly enhance data workflows in PostgreSQL-based systems.
By integrating TimescaleDB with pglogical, organizations can leverage the best of both time-series capabilities and sophisticated replication tactics to meet modern data demands.
Related reading
- is Lost update possible with RAFT?
- Is making multiple shards of your data with multiple threads minimize the training time?
- Is multi-AZ RDS really worth it?
- Is MVVM pointless?
- Is mongodb running?
- Is MongoDB v2.6's WriteConcern Broken?
- Is my understanding of a Distributed Lock correct?
- Is one source to many target cluster replication supported by YugabyteDB’s 2-DC async replication mechanism?

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.