*How we migrated a Qatar government entity's 50 TB EDB PostgreSQL database, TimescaleDB included, to community PostgreSQL: live replication, content-level data validation, and a near-zero-downtime cutover.* ## A Success Story for HexaCluster and Mannai - delivered using HexaRocket We are excited to share one of the [HexaRocket](https://hexarocket.com)’s success stories involving a migration of a 50 TB - EDB PostgreSQL database with TimescaleDB, to Community PostgreSQL with TimescaleDB. Mannai, our Partner from Qatar, reached out to us about this migration for a government entity in Qatar (Confidential), with a challenge that the migration must be executed faster and online, without impacting the business operations. Before we begin, we sincerely want to acknowledge the efforts and expertise by Mannai, especially, the Service Delivery Manager, Satish Kumar Sadhu, and his team, who have ensured an efficient planning, communication and the execution of this Project. [Mannai](https://mannai.com/) served as the prime implementation and delivery partner for this migration, leading the overall project planning, architecture assessment, customer coordination, validation, testing, and production cutover. HexaCluster provided the HexaRocket migration platform and worked closely with the Mannai team to address the specialized migration requirements of this large-scale PostgreSQL environment. ![image](https://hexacluster.ai/uploads/1784707212290-edbtopg.png) The project that was originally considered easily achievable was understood as challenging. The scale explains why – 50 TB of data, 1 to 3 TB of [write-ahead log (WAL) ](https://www.postgresql.org/docs/current/wal-intro.html) generated every day, nearly 300 GB of WAL segments generated during Peak, and Millions of events are ingested per hour. An additional requirement was to perform the entire migration from a Standby database, but not from Primary. Before engaging HexaCluster, Mannai conducted a comprehensive technical evaluation and solution assessment for the PostgreSQL migration. This included evaluating PostgreSQL native logical replication, open-source replication tools, and approaches from multiple PostgreSQL technology providers. Based on this assessment, it was determined that the project’s scale, performance requirements, and near-zero downtime objectives required a specialized migration tool. HexaCluster was then engaged to complement Mannai’s implementation expertise with its advanced migration technology, ensuring the successful delivery of the migration. Following the technical evaluation, Mannai selected [HexaRocket](www.hexarocket.com) as the migration platform best suited to meet the project's scale, performance, and near-zero downtime requirements. Together, Mannai and HexaCluster completed multiple dry runs and successfully executed the production migration with zero data loss and live replication. Within 3 weeks, we were able to complete multiple dry runs, and also complete the Production database cutover, with zero data loss, and live replication. In this article, we are going to share some details on the complexity and the approach and how HexaRocket made it seamless. ![image](https://hexacluster.ai/uploads/1784707088676-WhatwasachievedusingHexaRocket.png) ## Why was this genuinely hard using Logical replication or other Open-Source replication tools On paper, this migration is routine. EDB PostgreSQL and community PostgreSQL may be similar engines at heart, and TimescaleDB runs happily on both. What changes everything is the write volume - this database ingested millions of events per hour, around the clock, producing 1 to 3 TB of WAL on an ordinary day and more on a busy one. During the peak hours, the workload does generate between 150 GB to 300 GB of WAL segments per hour. --- --- The customer also required a live, continuous replication into the new environment before cutover, not a dump-and-restore weekend. The textbook answer would be PostgreSQL's native [logical replication](https://www.postgresql.org/docs/current/logical-replication.html), but at this change rate it becomes nearly impossible to operate. The initial synchronization of 50 TB has to complete while the replication slot forces the source to retain days of WAL. The subscriber must then keep pace with terabytes of daily change or fall ever further behind. And, critically, [logical replication does not replicate DDL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html): schema changes simply do not flow. That last restriction collides head-on with TimescaleDB. If you have not tried it before, [TimescaleDB](https://docs.timescale.com/use-timescale/latest/hypertables/) is an extension that turns large tables into hypertables, automatically partitioning them into many smaller chunk tables. It is built exactly for heavy streams of timestamped data - IoT device telemetry, financial ticks, application metrics. Our customer used it on their busiest tables, which means the database was creating new chunk tables on the fly as data for new time ranges arrived. A replication approach that cannot carry DDL falls apart when the schema itself changes many times a day. One more constraint shaped the whole design - the source system was already fighting disk I/O (IOPS) saturation at peak. Whatever we did, we could not add heavy read pressure to the production primary. ## First, a baseline - what does 50 TB actually take? We began with a deliberately unoptimized, single-pass full load of the entire dataset using HexaRocket. We can apply Parallel workers to migrate multiple tables in parallel. It took about 3 days. Remember that this was the first dry-run. We are aware that this number was never going to survive with a real cutover plan, but it gave us exactly what we needed: per-table load timings and a clear picture of the kind of data each table held. From there, we knew where the time was going and what to parallelize. ## Accelerating the initial load to ~1.5 TB per hour HexaRocket is built exactly for this situation. It parallelizes data migration across many tables at once and, more importantly here, it parallelizes within a single table - multiple worker processes copy disjoint slices of the same large table (including individual timescaledb chunks) concurrently, so even the biggest hypertables load at full speed. After configuring parallel workers based on the baseline analysis, we sustained roughly 1.5 TB per hour, bringing the initial load of the full 50 TB down from about 3 days to 28 hours in repeated dry-runs. Three more decisions made that number, and the system around it, hold up - - **Indexes were dropped on the target during the load** and rebuilt later, once the data was validated. Loading into index-free tables is dramatically faster than maintaining indexes row by row. - **Data was distributed across multiple [tablespaces](https://www.postgresql.org/docs/current/manage-ag-tablespaces.html) on separate physical disks.** The customer was already living with IOPS saturation on the source, so we designed the target's storage layout to spread I/O from day one. - **Everything ran against a standby, not the primary.** Both the initial load and the change data capture that followed read from an EDB standby server, so the production primary never felt the migration. ## The Architecture ![image](https://hexacluster.ai/uploads/1784707565028-architectureedbtopg.png) *HexaRocket reads from the EDB standby (initial parallel load, then ongoing changes) and writes to community PostgreSQL with TimescaleDB, with data spread across multiple tablespaces. Applications keep writing to EDB PostgreSQL until cutover day.* ## A production-grade, highly available target The destination was never meant to be a single server. We built the target as a Patroni-managed high-availability cluster - a primary with a synchronized standby and automated failover - so the customer inherited resilience, not just a copy of their data. Bootstrapping Patroni across a 50 TB dataset is itself a serious undertaking; the initial cluster build takes real time at that scale. We completed it successfully, and the applications cut over onto an HA platform from their very first transaction, rather than waiting for high availability to arrive as a later project. ## Not every table needs real time: a two-pool strategy With 1-3 TB of change flowing through the system daily, keeping every table on a real-time pipeline would have been the hard way for no benefit. HexaRocket provided a detailed clarity in its Monitoring Dashboards, on the type of DMLs observed per table, during our dry runs. So, we sat down with the customer's application teams and categorized the tables into two pools. - **The OLTP pool: live CDC.** Transactional tables that the business reads and writes moment to moment went onto HexaRocket's change data capture (CDC) replication; streaming changes continuously to the target. - **The OLAP pool: scheduled batch sync.** HexaRocket provides a simple switch on its UI to move a Table from a log-based replication (WAL segments are decoded) to a Batch-based replication. Analytical tables were synchronized on a schedule (every 15 minutes to every hour) using a high-watermark approach - each run records the highest watermark-column value it has applied, and the next run picks up everything newer. These tables stayed within roughly 10-15 minutes of the source, comfortably inside what their analytics required. The effect was that the real-time pipeline stayed lean and fast for the tables that genuinely needed it, while the heavy analytical tables synced efficiently in batches. ## Validation that goes beyond row counts A migration is only as good as your proof that nothing was lost. Counting rows is necessary (HexaRocker supports row count validation), but nowhere near sufficient, so we ran HexaRocket's data validation, which compares the actual data between source and target and reports every inconsistency it finds, not just mismatched counts. We enabled the built-in Validation during data migration. Additionally, using the HexaRocket’s offline data validation feature, these checks ran continuously against the replicated tables. This is what moved the customer from hopeful to confident - they could see, table by table, that the migrated data was complete and correct, with no silent corruption. Only then did we rebuild the indexes on the target, by pausing the replication only for the specific tables on which we were rebuilding Indexes and start preparing for cutover. ## A two-phase cutover We designed the switchover in two phases so the final day would be as small and boring as possible. **Phase 1: hand the OLAP tables over early.** A few days before the main switchover, the analytical tables were handed to the customer's ETL team, who began running their ETL jobs against both EDB PostgreSQL and community PostgreSQL in parallel. By cutover day, analytics was already living on the new platform. **Phase 2: converge the OLTP tables.** With analytics out of the way, we focused entirely on the transactional tables under live CDC, running data validation and count checks continuously to confirm that source and target matched in real time. On switchover day the sequence was short and rehearsed: the application teams paused traffic to EDB PostgreSQL, we let the remaining changes drain to the target, ran a final count validation across all tables, synchronized the sequence values, and pointed the applications at community PostgreSQL. Writes resumed on the new platform after a pause, not an outage. ## The outcome The full 50 TB estate now runs on community PostgreSQL with the open-source [TimescaleDB extension](https://github.com/timescale/timescaledb), migrated without a single data issue and cut over with near-zero downtime. - **No more proprietary licensing.** The customer completed the move from a commercial distribution to open source, a path we have refined across many [commercial-database-to-open-source migrations](https://hexacluster.ai/commercial-databases-to-open-source-migration). - **The same TimescaleDB capabilities**, now on a community platform they fully control. - **A storage layout built for their I/O profile**, with data distributed across multiple tablespaces and physical disks, directly addressing the IOPS pain they had lived with on the source. What made this work was not one trick. It was a baseline measured honestly, parallelism applied where the data said it would pay off, a replication strategy shaped with the application teams rather than imposed on them, validation the customer could verify for themselves, and a cutover runbook detailed enough that the day itself held no surprises. Our thanks to Mannai for the partnership throughout the engagement. ## Planning a PostgreSQL migration? If you are weighing a move from EDB PostgreSQL, Oracle, or another commercial database to PostgreSQL, this is exactly what we do. HexaRocket handles parallel initial loads, live CDC, scheduled batch sync, and content-level data validation at terabyte scale, and our engineers have run it against production systems that cannot afford to stop. Explore our [database migration to PostgreSQL services](https://hexacluster.ai/database-migration-to-postgresql) or [talk to our team](https://hexacluster.ai/contact-us). HexaCluster provides end-to-end migration and modernization services, including [application migration and modernization](https://hexacluster.ai/application-migration-and-modernization), [database migration](https://hexacluster.ai/database-migration-to-postgresql), and PostgreSQL consulting such as [performance tuning](https://hexacluster.ai/performance-tuning), [health audits](https://hexacluster.ai/architectural-health-audit), [managed DBA services](https://hexacluster.ai/managed-dba-services), and [24/7/365 support](https://hexacluster.ai/support-plans). To start a conversation or explore how we can support your migration journey, please contact us at connect@hexacluster.ai [Subscribe to our Newsletters](https://hexacluster.ai/#:~:text=Subscribe%20to%20Newsletters) and Stay tuned for more interesting topics.

⚡ Automated Schema Conversion

🔄 Real-Time Data Movement

🚀 End-to-End Modernization