pgEdge Posts from Hari Kiran

Implementing pgBackRest for Backup and Restore in pgEdge

Thu, 03 Jul 2025 06:37:00 GMT

pgEdge enhances PostgreSQL by enabling distributed, multi-active database clusters designed for low-latency, globally scaled applications. However, distributed systems introduce new challenges in data protection and disaster recovery. In this blog, we'll outline the steps and best practices you should follow when implementing and maintaining a reliable backup and restore strategy for pgEdge environments using pgBackRest. pgBackRest is a robust, high-performance backup tool designed for PostgreSQL that offers features such as:

Full, differential, and incremental backups

Compression and encryption

Parallelism and delta restores

Point-in-Time Recovery (PITR)

Seamless integration with WAL archiving

When combined with pgEdge, pgBackRest ensures data resilience across distributed nodes by supporting geographically redundant backups and rapid restoration of services after network interruption or failure.In this blog, we'll:

Define a consistent and reliable backup process for pgEdge clusters.

Share steps to recover from data loss, node failures, or full-cluster outages.

Guide both automated and manual backup/restore procedures.

help you support compliance with organizational RTO (Recovery Time Objective) and RPO (Recovery Point Objective) policies.

We'll define the process for backing up and restoring PostgreSQL databases in a pgEdge cluster with pgBackRest. You can use this information to ensure consistency, reliability, and disaster recovery readiness in a distributed pgEdge PostgreSQL cluster. This information will be useful for you if you manage a:

production or staging pgEdge cluster.

a team responsible for backups and recovery.

a cluster running pgEdge PostgreSQL 15+ with pgBackRest installed.

Prerequisites

Before working your way through this blog, you should ensure that you have:

An installed and operational pgEdge cluster

With pgBackRest installed on each node (or a centralized backup host)

PostgreSQL WAL archiving is enabled (this is prompted during cluster setup)

a configured backup repository (either posix or S3-compatible storage)

Passwordless SSH access for centralized backup

You should also ensure that your cluster is running version 25.X of the pgEdge CLI:

Configuring pgBackRest on an Existing Cluster

There are multiple ways to deploy pgBackRest with a pgEdge cluster; if you are spinning up a new pgEdge cluster, you can deploy pgBackRest at the same time by using the cluster module to define a .json file that includes the pgBackRest specifications, and then initialize your cluster.In the example that follows, we'll add pgBackRest to an existing pgEdge cluster . To accomplish this, you'll use the pgEdge CLI to install and configure the pgEdge backrest bundle. This Multi-master-enabled pgBackRest bundle is designed specifically for pgEdge use cases.The following are the steps involved in setting up the backrest:

Install the latest version of the pgEdge backrest source code bundle.

Create a pgBackRest stanza with the
set-postgresqlconf
API.

Modify the PostgreSQL
pg_hba.conf
file and reload the configuration.

Modify the stanza to configure the backup.

Identify your backup repository; the current options are posix and S3.

Update pgEdge Postgres to provide details like user identities, port information, and data directory location.

Configuring pgBackRest on an Existing pgEdge Cluster

First, we'll use pgEdge to install pgBackRest on each node of the cluster:Then, we'll use the API to update the file in preparation for configuring pgBackRest:Next, we'll use the API to update the pg_hba.conf file, configuring authentication for pgBackRest:Then, we'll reload the server configuration so the changes take effect:Next, we'll configure our backup and create the backup stanza:Then, we start pgBackRest:After starting pgBackRest, we can review a list of backups:

How Not To Use PostgreSQL DDL Replication

Tue, 13 May 2025 06:09:38 GMT

Introduction

PostgreSQL's native logical replication enables selective replication of data changes from a publisher to one or more subscribers. However, it doesn't replicate Data Definition Language (DDL) commands, such as , , or statements. This means that schema modifications made on the publisher must be manually applied to each subscriber node to maintain consistency. The official PostgreSQL documentation highlights this limitation and suggests using tools like for initial schema synchronization, with subsequent changes requiring manual intervention on each subscriber node.If you're a developer or DBA working with logical replication, you should:

Use pgEdge or other products or tools for complex or distributed setups.

Plan ahead for
TABLE REWRITE
scenarios.

Implement CI/CD pipelines that monitor schema changes.

Stay informed with PostgreSQL’s roadmap and feature announcements.

Above all, don't assume logical replication will automatically replicate schema changes!

Choosing an Extension that Bridges the DDL Replication Gap

To address the lack of native DDL replication in PostgreSQL, community-driven and commercial products and tools have emerged, each offering varying degrees of automation and flexibility.pgEdge
pgEdge takes an advanced approach by offering built-in, seamless DDL replication within its distributed PostgreSQL platform. Any schema changes made on one node are automatically and reliably propagated across all other participating nodes in a pgEdge cluster. This automation significantly reduces operational complexity, particularly in geo-distributed and multi-active environments. By handling both data and schema consistency out of the box, pgEdge enables truly distributed PostgreSQL deployments without the usual pain points.pglogical
pglogical is a dual-licensed PostgreSQL extension that extends logical replication capabilities with support for DDL replication. The community version of pglogical provides the function, which captures DDL statements and sends them to a replication queue for execution on each subscriber node. This allows for automatic propagation of schema changes across instances, eliminating the need for manual synchronization, but requires careful configuration and compatibility checks to ensure DDL changes execute identically on all subscribers.

Thoughts on Production Implementation

While these extensions offer much-needed solutions for replicating DDL changes, it’s critical that you approach their implementation and daily use with care. It is best not to implement DDL replication until you fully understand the limitations, operational risks, and maintenance requirements of the replication solution you choose.Blindly enabling DDL replication without considering schema compatibility, scenarios, and transactional integrity can lead to future downtime, potential replication breakages, and unfortunately, data inconsistency. Simply put, DDL replication is not a “set it and forget it” feature, especially in a production environment.To avoid replication pitfalls:

Always test schema changes and DDL replication in a staging environment that mirrors production.

Validate how your replication solution handles complex changes like column type alterations, constraint updates, or table rewrites.

Monitor your database for subtle drift between publisher and subscriber schemas.

Treat DDL replication as a controlled process within your CI/CD pipeline—not an ad-hoc change.

In short, the wrong way to use PostgreSQL replication (especially DDL replication) is to assume it works like magic out of the box. The right way to use replication is to leverage purpose-built tools like pgEdge with strong operational discipline to ensure safe, predictable, and consistent schema evolution across distributed PostgreSQL systems.

Comparing Traditional PostgreSQL Replication vs. pgEdge

As you can see, pgEdge significantly simplifies operations while adding robust capabilities.

Best Practices When Using DDL Replication

If you're using or planning to use DDL replication, keep these best practices in mind:

Apply additive schema changes to subscriber nodes first, or simply use the pgEdge AutoDDL feature.

Avoid making schema changes during peak replication times.

For example, if you have a busy system and a relatively large table, you might want to split the following command into multiple SQL statements to avoid extensive table rewrites and locking:That command could be split into multiple SQL statements (as follows):After making changes to your table, always:

Test DDL changes in a staging environment before applying them to production.

Monitor replication status closely for early detection of schema mismatch.

Use automation tools wherever possible to reduce human error.

When Not to Use DDL Replication

There are still situations where you might choose not to use DDL replication, such as:
When schema stability is high and changes to your DDL are rare.

In single-region configurations with low complexity.

When migration and synchronization are handled manually and controlled.

With pgEdge, you can use the spock.repair_mode function to control DDL and data replication.

FAQs

What is DDL replication and why does PostgreSQL not support it natively?
DDL replication refers to the propagation of schema changes across databases. PostgreSQL’s native logical replication currently doesn’t support DDL replication due to architectural limitations.How does pgEdge handle TABLE REWRITE operations?
pgEdge tracks schema changes and manages table rewrites internally to ensure consistency across all nodes.Can I use pgEdge for multi-cloud deployments?
Yes. pgEdge is designed to manage geo-distributed, multi-cloud, and multi-region PostgreSQL deployments.Is there performance overhead when using pgEdge DDL replication?
Minimal. pgEdge optimizes the replication of DDL events without significantly impacting runtime performance.How can I migrate my existing logical replication setup to pgEdge?
You can transition to pgEdge by first exporting your schema definition and data, then initializing pgEdge clusters, and finally leveraging its replication features for seamless sync.For more information about pgEdge Distributed PostgreSQL, visit the pgEdge website .

Transitioning RDS Applications to a Multi-Cloud Architecture with pgEdge Platform

Tue, 04 Mar 2025 06:01:00 GMT

Introduction

As enterprises increasingly adopt multi-cloud and hybrid cloud strategies, managing data across a distributed environment becomes a significant challenge. Many organizations rely on Relational Database Services (RDS) from providers like AWS, Azure, or Google Cloud. While these solutions offer robust performance, they often limit residency to a single cloud provider, creating barriers for distributed deployments.

The Problem: Cloud Limitations

Vendor Lock-In: Cloud providers design their services to work best within their own ecosystem. While this integration boosts simplicity, it ties the user to a single vendor, limiting flexibility and scalability.Latency and Performance: Applications spanning multiple regions on a single provider can suffer from latency issues. Data stored in a cloud provider’s RDS can introduce delays when accessed from another cloud or an on-premise environment.Data Governance and Compliance: Some geographic regions and industries impose data residency requirements. Traditional RDS solutions lack the tools to manage data seamlessly across locations while meeting compliance needs.Disaster Recovery: Single-cloud databases create a single point of failure. A region-specific outage can cripple operations, underscoring the need for resilient and distributed database architectures.

Moving from RDS to a Distributed Architecture

Understanding the Need for Distributed Architectures

Why traditional RDS limits scalability and flexibilityRelational Database Services (RDS) offered by cloud service providers are designed to integrate tightly within their ecosystems. While this provides a seamless experience for single-cloud operations, it limits scalability and flexibility for organizations that would benefit from using a more distributed strategy. Vendor lock-in is a significant drawback; over time, migrating applications to other platforms or extending operations across providers becomes even more cumbersome. Additionally, latency and resiliency challenges can arise when trying to serve geographically dispersed users from a non-localized system or ensuring failover.Key benefits of adopting a multi-vendor approachBy leveraging a distributed, multi-cloud database solution, your organization can eliminate vendor lock-in, reduce latency globally, and enhance fault tolerance. Using multiple cloud vendors can help your business comply with regional data residency laws by deploying databases in specific jurisdictions while maintaining centralized control.

The Value of pgEdge Platform for Cross-Cloud RDS Applications

pgEdge Platform builds on PostgreSQL, transforming a simple database cluster into a distributed cross-cloud database platform. pgEdge Platform uses the Spock extension to enable logical replication across multiple nodes that reside on one or more cloud providers and on-prem systems, ensuring low-latency access and synchronization of data. Its multi-master (active-active) geo-distributed architecture and advanced networking capabilities remove pain points from traditional RDS systems, providing a scalable, resilient solution for modern enterprises.Here’s how:

Multi-Cloud and Hybrid Cloud Compatibility

pgEdge Platform operates across multiple cloud platforms (AWS, Azure, GCP) and can integrate with on-premise environments for a hybrid architecture. This eliminates vendor lock-in, giving businesses the freedom to deploy and access their data from anywhere.

Distributed PostgreSQL

With built-in support for distributed PostgreSQL, pgEdge enables logical replication with the Spock extension, providing synchronization across different regions and clouds, ensuring low-latency access and better performance for distributed applications.

Compliance and Data Sovereignty

pgEdge Platform allows precise control over where your data resides. Data residency is critical when adhering to GDPR, HIPAA, and other regional compliance mandates.

Enhanced Resiliency

By distributing data across cloud providers and regions, pgEdge Platform mitigates the impact of outages. Even if one provider or region fails, applications can continue functioning seamlessly.

Simplified Management

Unlike managing separate databases, pgEdge Platform centralizes the management of a distributed PostgreSQL database, simplifying operations and reducing overhead.

Preparing for the Move to Multi-Cloud

Prerequisites: Assessing your current RDS setup

Before moving to pgEdge Platform, it’s crucial to audit your existing environment. Key factors to evaluate include:

Database size and structure

Peak usage and geographic distribution of users

Integration points with other services

Data residency requirements

Understanding these factors will help define your migration goals and avoid disruptions.

Analyzing workload and application requirements

Map out your application’s workload requirements, such as read/write patterns, latency sensitivity, and compliance constraints. Allow those regions with the highest user activity to guide your database distribution strategy. Also, evaluate how your application handles downtime and plan for any necessary adjustments during the migration process.

Setting up the necessary cloud infrastructure

Prepare your target infrastructure across cloud providers (e.g., AWS, Azure, GCP). This involves provisioning compute resources, configuring VPCs, and ensuring connectivity between clouds. Ideally, use tools like Terraform or Kubernetes for automated deployments to maintain consistency.

Step-by-Step Migration to pgEdge Platform

Step 1: Setting up pgEdge Platform on multiple providers

Deploy PostgreSQL nodes in each cloud region based on user proximity and workload distribution.

Step 2: Configuring logical replication with Spock for PostgreSQL

Install the Spock extension on your existing RDS instance and on all pgEdge nodes.

Define replication sets and configure Spock to synchronize data between regions.

Test replication by inserting sample rows into the RDS database and verifying their presence in the pgEdge nodes.

Step 3: Testing data synchronization across regions and cloud providerss

Run latency tests and validate data consistency across the distributed setup. Use PostgreSQL’s
pg_stat_replication
view to monitor replication lag.

You can review my 2-part blog series on Migrating from AWS Aurora to pgEdge for detailed step-by-step instructions:

Part I

Part II

Troubleshooting and Maintenance in a Multi-Cloud Environment

Diagnosing common replication issues

Replication in a distributed system can occasionally face disruptions due to network interruptions or configuration errors. pgEdge provides tools and logs you can use to diagnose issues. Use the pg_stat_replication view to monitor replication lag and identify nodes that might not be synchronized properly.Verify network configurations, such as VPNs or peering connections, for connectivity issues between cloud providers.

Handling failover scenarios effectively

pgEdge's distributed architecture ensures high availability through automatic failover mechanisms. In the event of a node failure, pgEdge reroutes traffic to healthy nodes. Configure failover priorities using PostgreSQL’s streaming replication settings.

Continuous monitoring for security and uptime

pgEdge integrates with monitoring platforms like Prometheus and Grafana, allowing you to visualize metrics such as uptime, replication status, and query performance. Set up custom alerting mechanisms for unusual activities, such as unexpected spikes in replication lag or failed connections, to proactively address issues.

Key Benefits Realized with pgEdge Distributed Postgres

Enhanced scalability and performance

pgEdge enables horizontal scaling by distributing PostgreSQL clusters across multiple cloud regions. This ensures that applications can handle increased workloads without compromising performance. Users benefit from faster query execution times as data is accessed from the closest replica.

Improved fault tolerance and availability

By replicating data across multiple clouds and regions, pgEdge mitigates the impact of outages. Even if a specific cloud provider experiences downtime, applications remain operational, leveraging the resilience of the distributed architecture.

Simplified management across clouds

pgEdge centralizes the management of multi-cloud PostgreSQL databases, reducing the complexity of operating individual instances. Administrators can manage replication policies, monitor performance, and enforce compliance rules from a unified interface, streamlining database operations.

Bridging Healthcare’s Data Divide: How pgEdge Distributed Postgres and HAPI FHIR Delivered Scalability and Security

Fri, 06 Dec 2024 15:14:00 GMT

The healthcare industry is in the midst of a data revolution. From patient records to medical images, the demand for seamless, scalable, and secure data management has never been greater. At the heart of this transformation is Fast Healthcare Interoperability Resources (FHIR)—a framework that makes healthcare data accessible and shareable. But as the scale and complexity of healthcare data grow, so do the challenges of managing it effectively.One healthcare provider faced these challenges head-on, transforming their approach to FHIR data management with a combination of HAPI FHIR and pgEdge Distributed PostgreSQL. This story highlights the power of innovative technology to drive meaningful change, showing what’s possible when the right tools come together to tackle complex challenges.

What to Do When Growth Becomes a Challenge

This forward-thinking healthcare provider had a clear mission: to deliver better care by leveraging data. But their growing reliance on FHIR resources was testing the limits of their existing infrastructure. The sheer volume of data—and the need to manage it across geographically distributed systems—introduced a web of challenges:

: Global operations require high availability and multi-region replication. Traditional PostgreSQL, while powerful, struggled with the demands of horizontal scaling and geographic distribution.

: HAPI FHIR uses PostgreSQL's OID data type to store large binary objects like medical images and documents. Unfortunately, PostgreSQL’s native replication couldn’t handle these large objects, risking incomplete or inconsistent data across regions.

: Healthcare data is among the most sensitive information managed today. Ensuring compliance with HIPAA and GDPR while maintaining data integrity and accessibility was non-negotiable.

Faced with these obstacles, the provider needed a solution that could deliver distributed, scalable data management without compromising on performance or compliance.

Building the Right Solution: HAPI FHIR Meets pgEdge Distributed Postgres

Recognizing the scale of the challenge, the healthcare provider’s database team leveraged pgEdge to craft a solution that combined the robust API capabilities of HAPI FHIR with the power of distributed PostgreSQL. Here’s how it all came together.

Step 1: Overcoming PostgreSQL’s Replication Limits with Large Object Logical Replication (LOLOR)

The first hurdle was clear: PostgreSQL’s native logical replication couldn’t handle the OID data type used by HAPI FHIR to store large objects. This limitation threatened the consistency of critical healthcare data across regions.To address this, we implemented pgEdge’s LOLOR extension. By extending PostgreSQL’s native capabilities, LOLOR enabled seamless replication of OID-based large objects across the distributed database. Medical images, scanned documents, and other large FHIR resources could now be securely and reliably synced across regions without compromising performance or data integrity.

Step 2: Leveraging Seamless HAPI FHIR Integration

HAPI FHIR’s out-of-box compatibility with pgEdge PostgreSQL eliminated the need for extensive customization. This allowed the team to focus on scaling the solution rather than troubleshooting integration issues. With this foundation, it set the stage for rapid deployment and future growth.

Step 3: Using Multi-Master Replication to Create a Distributed Database and Reduce Latency

Next, pgEdge’s distributed PostgreSQL was configured to operate across multiple geographic locations. Multi-master replication ensures that even if one region experiences downtime, other data centers will take over instantly, maintaining uninterrupted service.The distributed architecture also minimized latency by routing queries to the nearest data center, delivering faster response times for users around the globe. With automatic failover capabilities, the system is primed to handle spikes in demand and scale effortlessly with growing data needs.

Step 4: Ensuring Compliance and Security

Handling sensitive healthcare data meant compliance was a top priority. The built-in auditing tools and support for the extension provided detailed monitoring and access control, ensuring HIPAA and GDPR requirements were met.Automated backups and recovery tools added an extra layer of security, enabling quick rollbacks if needed. This comprehensive approach gave the provider peace of mind, knowing their data was secure and fully compliant.

The Results: A New Standard for Healthcare Data Management

: With the LOLOR extension, large FHIR resources like medical images are now reliably replicated across all regions, ensuring data consistency and availability.

: The distributed setup means the system remains operational even during regional outages, with automatic failover ensuring uninterrupted service.

: By routing queries to the nearest data center, the provider reduced latency and improved user experience, regardless of location.

: As data volumes grow, the system can scale horizontally without sacrificing performance.

: Robust auditing and backup features keep sensitive data safe and compliant with industry regulations.

Looking Ahead: A Foundation for Growth

With their new system in place, the healthcare provider is ready to embrace the future of data-driven care. The combination of HAPI FHIR’s powerful API framework and pgEdge’s distributed Postgres capabilities has not only solved today’s challenges but also prepared them for the demands of tomorrow.As healthcare data continues to expand in both size and importance, solutions like this one set a new standard for how the industry can manage, secure, and leverage its most critical resource: information.

How to Migrate from AWS Aurora to pgEdge for Low Latency, Multi-region and Multi Master Distributed Postgres: Part 2

Thu, 25 Jul 2024 05:45:59 GMT

As discussed in the Part-1 blog post , moving to a fully open, distributed PostgreSQL database with multi-master, multi-region and multi-cloud capabilities can ensure applications are responsive and always available.Migrating to pgEdge distributed PostgreSQL involves a series of carefully planned and executed steps to ensure data integrity, minimal downtime, and a smooth transition. Below is a detailed explanation of the high-level approach.

High-level Approach:

Step 1: Create PostgreSQL publications on Aurora

Start by setting up two publications on the AWS Aurora database. A PostgreSQL publication is a set of changes (inserts, updates, and deletes) that is replicated to subscribers.

Step 2: Create replication slots on Aurora

Next, create two PostgreSQL logical replication slots on Aurora. These slots will help keep track of the replication progress and ensure data consistency during the migration.

Step 3: Invoke pg_dump on Aurora

Use pg_dump to take a snapshot of the Aurora database. The snapshot reflects the state of your database and data at a specific point in time, maintaining data integrity.

Step 4: Restore the backup on pgEdge Instances

On each of two pgEdge Platform instances, use pg_restore to restore the backup taken with pg_dump.

Step 5: Create Subscriptions on pgEdge

Create subscriptions on both pgEdge instances to connect to the publishers and replication slots on Aurora.

Step 6: Extract Current OID from pg_subscription

Retrieve the current OID (Object Identifier) for each subscription from the pg_subscription table on the pgEdge instances.

Step 7: Grab the LSN from Aurora Replication Slots

Fetch the Log Sequence Number (LSN) from the replication slots created on Aurora. The LSN is crucial for ensuring that replication starts from the correct point.

Step 8: Advance Replication Using pg_replication_origin_advance()

Use the pg_replication_origin_advance() function on the pgEdge instances to advance to the start replication point using the LSN retrieved from Aurora.

Step 9: Enable Subscriptions on pgEdge Nodes

Enable the subscriptions on both pgEdge nodes to start the replication process.

Step 10: Check & Validate Replication Status

Finally, check and validate the status of the replication to ensure that it is functioning correctly.Example: The following code snippets demonstrate the commands you'll perform during a migration to pgEdge Platform. Note that the commands are performed on the host of a pgEdge Platform node:

Invoke
pg_dump
to take a backup of the Aurora source database in a directory format:

Restore the backup taken from Aurora:

On node n1 of your pgEdge cluster:

On node n2 of your pgEdge cluster:

After validation, drop the subscriptions from Aurora to nodes n1 and n2:

On the Aurora instance, confirm that the logical replication slots are cleaned up:

After the cutover and before going live, run a vacuum on both pgEdge nodes:

How to Migrate from AWS Aurora to pgEdge for Low Latency, Multi-region and Multi-Master Distributed Postgres: Part 1

Wed, 24 Jul 2024 17:16:21 GMT

Introduction

In today's rapidly evolving digital landscape, enterprises need innovative solutions to enhance their database management systems and practices. The goal of most organizations is to ensure their applications are always on, always available and always responsive, while meeting ever-changing business demands. This is where a fully-distributed PostgreSQL platform comes into play.In this 2-part blog series, we'll explore the best practices and a high-level architectural approach to perform a near zero downtime migration to pgEdge distributed PostgreSQL. We'll discuss the benefits realized and the process that ensures a seamless transition to an open, standards-based distributed PostgreSQL platform.

High Availability and Scalability

pgEdge is designed to deliver high availability and low latency across geographic regions and cloud environments. pgEdge achieves this through its advanced multi-master replication capabilities. This replication model allows for write operations to be distributed across multiple nodes, multiple regions, and multiple clouds, significantly reducing write latency and improving overall availability. Moreover, pgEdge's distributed nature ensures that as your data grows, your database system can easily scale horizontally to meet your business demands.

Open-Source Flexibility and Community Support

pgEdge brings to the table a critical combination of flexibility and robust support from seasoned PostgreSQL experts from the global development community. With pgEdge, your enterprise has the freedom to customize your database solution to meet your specific needs - this can be restricted when you're tied to a proprietary solution. Additionally, the open-source nature of pgEdge means that it is continuously improved by architects and developers who have been part of the PostgreSQL community for decades, ensuring that the platform stays at the cutting edge of database technology and security.

Migration Path to pgEdge Distributed Postgres with Near-Zero Downtime

1. Planning and Preparation

Migrating to pgEdge involves meticulous planning and preparation to ensure a smooth transition. pgEdge experts help you conduct a thorough assessment of your current database architecture, data volume, and application dependencies to assess the scope of the migration process. During the assessment, pgEdge can help identify any schema modifications or application adjustments that will simplify and streamline the migration.

2. Proven Migration Recipe - Configuring Data Replication

During this step, data replication from the existing Aurora database to pgEdge is established. This is facilitated by pgEdge's compatibility with PostgreSQL, allowing you to use logical replication to synchronize data in real-time. This step ensures that all data remains current on both the source and target databases during the migration process.

3. Application Dual-Writing

To minimize downtime, your application is initially configured to write simultaneously to both Aurora and pgEdge. This dual-writing phase is critical for testing the pgEdge environment under load and ensuring data integrity and application performance are maintained.

4. Incremental Data Syncing and Testing

While your application is writing to both pgEdge and Aurora, the incremental data sync continues - during this time, extensive testing is the focus. This testing phase includes verifying data consistency, performance benchmarking, and ensuring that all of your applications function correctly with pgEdge.

5. Cutover and Transition

Once testing confirms that pgEdge meets or exceeds the performance and reliability of Aurora, the final cutover is planned. This involves redirecting all database traffic from Aurora to pgEdge, effectively completing the migration. The cutover is scheduled during a low-traffic period to minimize impact and is executed as quickly as possible to ensure near-zero downtime.

6. Monitoring and Optimization

After the migration, continuous monitoring is essential to ensure the stability and performance of pgEdge. This phase involves tuning configurations, optimizing queries, and making adjustments based on real-world workload patterns.

Key Considerations

Risk mitigation - throughout the migration process, risk mitigation is a priority. This involves having a robust rollback plan in case any issues arise during the cutover.

Data Integrity - ensuring data integrity includes comprehensive data validation steps both before and after the cutover to pgEdge.

Performance Benchmarking - conducting side-by-side performance testing with Aurora and pgEdge is crucial to validate the performance benefits of the migration.

Optimizing pgEdge Distributed PostgreSQL in your AWS environment

Wed, 06 Dec 2023 18:43:49 GMT

Introduction

Amid the considerable activity and announcements during AWS re:Invent and the Las Vegas PostgreSQL Meetup sponsored by pgEdge last week we were reminded of a recurring question that comes up for our customers and prospects who self-manage pgEdge Platform in their own AWS environments. We often get asked how to optimize individual node performance when running pgEdge Platform on Amazon EC2 instances, and how do you achieve IOPs performance comparable with Amazon’s RDS. Often there is an inherent performance improvement that comes from distributing the workload across the cluster. However, the key to harnessing the full potential lies in the careful configuration of PostgreSQL parameters, appropriate sizing and configuration of EBS volumes, selecting EC2 instance types with ample resources, refining indexing strategies, and maintaining vigilance through robust monitoring practices. Addressing these considerations will help ensure optimal performance across your pgEdge cluster. Let’s look at each of them in turn.

Optimize PostgreSQL Configuration:

Carefully tuning the PostgreSQL configuration parameters such as shared_buffers, effective_cache_size, work_mem, and a few more important ones to align with the available resources on your EC2 instance. This ensures that PostgreSQL effectively utilizes the allocated memory for optimal performance. As part of setting up the pgEdge Platform, we leverage pgtune with cluster orchestration to enhance the performance tuning process, ensuring optimal resource utilization and efficiency across the entire database cluster. Through automated configuration adjustments by pgtune, database nodes within the cluster can dynamically adapt to varying workloads and resource availability. This integration streamlines the management of PostgreSQL clusters, allowing administrators to fine-tune parameters, allocate resources effectively, and maintain optimal performance across the distributed environment.As a best practice, we configure the pg_wal directory on a separate mount point which stores the Write-Ahead Logging (WAL) files. This separation can prevent contention for disk resources, potentially reducing the risk of I/O bottlenecks. Moreover, on a separate mount point, the pg_wal directory can benefit from specific optimizations, like using a different storage device with higher write throughput. This configuration is particularly valuable in scenarios where write performance is critical, such as high-transaction-rate databases or systems with stringent durability requirements. When implementing this setup, we should carefully consider the storage characteristics and monitor I/O performance. Additionally, we'll employ parallelism to ensure that the subscriber remains reasonably up-to-date, especially during periods when the publisher is processing substantial data ingestions.

Properly Size and Configure EBS Volumes:

We access the workload thoroughly over discovery calls and help our Customers configure Elastic Block Store (EBS) volumes appropriately for achieving optimal PostgreSQL performance on EC2. A few of our key considerations include:Volume Type: Selecting the right EBS volume type based on the workload is essential. General Purpose SSD volumes offer a balance of performance and cost, while Provisioned IOPS SSD volumes, NVMe's provide predictable and dedicated I/O performance.Size and IOPS: Properly sizing the EBS volume involves determining the required storage capacity and ensuring sufficient provisioned I/O operations per second (IOPS). Align the volume size and IOPS with the database workload and performance requirements. Throughput: Consider the throughput requirements of your database workload and choose EBS volumes with adequate provisioned throughput. This is particularly important for workloads with high I/O demands.To sum up, choosing an appropriate Amazon Elastic Block Store (EBS) volume type for your workload (e.g., General Purpose SSD, Provisioned IOPS SSD) and size it according to your database requirements. Ensure that the IOPS and throughput of the EBS volume meet or exceed the desired performance level.

Leverage Instance Types with Sufficient Resources:

Selecting an EC2 instance type that adequately balances CPU, memory, and network performance for the PostgreSQL workload. Instances with high I/O capabilities, such as those optimized for storage (e.g., I3 instances), can significantly impact database performance. A few of our key considerations include:Understanding Resource Requirements: We begin by assessing the resource requirements of the PostgreSQL workload and consider factors such as CPU utilization, memory usage, and I/O patterns. We also understand the characteristics of the database, including read and write operations, to make informed decisions about the required resources.EC2 Instance Families: AWS offers a variety of EC2 instance families, each tailored to different use cases. For optimal PostgreSQL performance, we recommend Customers to consider instances from families Storage Optimized (I), or instances optimized for specific use cases like burstable performance (T instances).Storage Performance: Depending on the database size and I/O requirements, we help choose instances with appropriate storage options. Instances optimized for storage, such as the I3 family, provide high-speed NVMe SSD storage, enhancing I/O performance. We understand the relationship between EC2 instance types and their associated storage options to meet the IOPS requirements of your workload.GPU Instances for Specialized Workloads: In cases where the workload involves specialized computations or data processing that can benefit from GPU acceleration, we consider leveraging instances that come with GPU support. GPU instances can significantly enhance performance for tasks like parallel processing or data analytics.

Conclusion:

Achieving the same level of IOPs as seen with Amazon RDS might not always be fully possible, as the performance characteristics and optimizations of EC2 instances and RDS instances can vary. However, implementing these best practices will help you maximize the performance of your pgEdge nodes running on EC2.

Installing Distributed PostgreSQL with pgEdge Platform - A Comprehensive Guide

Thu, 16 Nov 2023 12:05:00 GMT

Introduction

PostgreSQL stands as a resilient and adaptable open-source relational database management system. In an era where data requirements constantly shift, organizations are increasingly delving into the realm of distributed databases to unlock scalability, enhance high availability, and boost overall performance. pgEdge Platform is one such solution that empowers you to implement a fully-distributed multi-master PostgreSQL environment. In this comprehensive guide, we'll walk you through the process of installing pgEdge Platform. pgEdge Platform is self-hosted, self-managed downloadable distributed PostgreSQL database. pgEdge also offers pgEdge Cloud, a fully managed database-as-a-service (DBaaS) – but this post focuses on pgEdge Platform.

Understanding Distributed PostgreSQL

PostgreSQL, by its fundamental design, operates as a single-node relational database that resides on a single host. In this configuration, all data resides on a solitary node; even partitioned tables are likely to remain in close proximity.To adapt PostgreSQL for use in distributed environments, third-party extensions come into play. These extensions offer functionalities like connection pooling, load balancing, and sharding, and when combined, allow a PostgreSQL database to span multiple servers. The distributed configuration grants an organization the power of scalability, ensuring that as data volumes grow, the database can seamlessly expand to accommodate the load. Moreover, high availability becomes a reality, as data redundancy across nodes minimizes the risk of a single point of failure, guaranteeing uninterrupted service. Distributed PostgreSQL also tackles key challenges, such as mitigating latency and optimizing query performance by storing data closer to where the data is needed, ultimately enhancing the user experience and system efficiency. It's vital to note that PostgreSQL isn't inherently tailored for distributed systems, and utilizing these extensions introduces inherent challenges, including the complexity of managing such a setup and potential performance trade-offs.

Introducing pgEdge Platform

pgEdge Platform is the most complete and advanced distribution of open-source fully-distributed PostgreSQL, supporting multi-master (active-active) replication.Database nodes operating with the pgEdge Platform have the ability to join clusters that extend across data centers and major cloud providers such as AWS, Azure, and Google Cloud, and can deploy on-premises on Equinix Metal. pgEdge Platform seamlessly functions on a wide range of standard hardware and operating systems.If you’re a Docker fan and would like to orchestrate a quick container-based two-node multi-master setup, see the instructions on this blog by my colleague Cady Motyka.

Preparing Your Environment

The prerequisites for installing pgEdge Platform are:

A local server or cloud instance running RHEL/CentOS/Rocky 9 or Ubuntu-22.04, with network traffic allowed on port 5432. AWS Cloud users can find the recommended Rocky 9
ami here
.

Passwordless sudo privileges via a non-root user

Passwordless SSH access into the server via a non-root user

Installing pgEdge Platform

Installation is a simple 2-step process:In any directory owned by non-root user, invoke the following command to create the pgedge directory and install nodectl:Then, move into the pgedge directory and initialize the database cluster:Replace the italicized placeholders in the above command with:● a name for the database superuser● a password for the database superuser● a name for the database.Names cannot be the name of an operating system superuser, 'pgEdge', or any of the PostgreSQL reserved words.

Configuring PostgreSQL Instances for Multi-master Replication

NodeCTL is the pgEdge Command Line Interface (CLI), used for installing, deploying, and managing components. The Spock extension provides multi-master (multi-active) replication for PostgreSQL versions 15 and 16. NodeCTL provides commands that allow you seamless interaction with the Spock extension.Using NodeCTL on each node, create the Spock components needed for replication. Here's the flow:First, we create a spock node. In our command, we provide a name for the node and a connection string that includes the network address, the name of an operating system user with root privileges (in our example, admin), and the database name (demo). The connection string is also followed by the database name. For example:Then, we create a replication set. In our command, we provide the replication set name and the database name. The node name (n1) and the replication set name (demo_replication_set) can be set to any valid value you choose, but you will have to reference them in future commands. For example:Then, we create the subscriptions. In our command, we provide a unique subscription name for each node, followed by a connection string that specifies the network address for the other node in the subscription. For example:

High Availability and Failover

The multi-Cloud, multi-master (active-active) architecture of pgEdge inherently ensures extremely high availability in a straightforward manner. If one or more nodes become unavailable, traffic seamlessly shifts to the remaining active nodes, eliminating any delays or lost transactions associated with passive nodes deliberating to elect a new active node. With pgEdge, disaster recovery and failover are seamlessly integrated, making it easy to plan and deploy. Unlike other high availability solutions, pgEdge significantly simplifies cross-cloud region failover support. For mission-critical applications, the idea of telling users, "Sorry, but our cloud provider's Eastern region is experiencing issues," is simply not acceptable. And the best part: zero downtime during maintenance!

Data Backup and Recovery

Backup and recovery is a critical concern for any database management platform, and in the case of the pgEdge Platform, we understand these functions are of paramount importance. We have semi-automated and designed pgEdge Platform with strict attention to Recovery Point Objective (RPO) and Recovery Time Objective (RTO) requirements. By customizing backup schedules and utilizing efficient recovery mechanisms, organizations can align their backup and recovery strategies with their RPO and RTO goals, ensuring that they meet their specific data recovery needs and minimize potential disruptions.Using NodeCTL to help with management is really straightforward - just install the backrest extension (our forked version of pgBackRest), and boom, you're ready to take backups. For example:

Conclusion

Distributed PostgreSQL, facilitated by pgEdge Platform, is a powerful solution for organizations seeking to unlock the full potential of their relational databases. This comprehensive guide has provided you with the knowledge and steps necessary to install, configure, and start using pgEdge Platform, the fully-distributed PostgreSQL environment. As data continues to play a central role in business operations, the ability to scale, maintain high availability, and optimize performance is critical. By following the steps outlined in this guide, you're well on your way to harnessing the benefits of distributed PostgreSQL with confidence and expertise.

Additional Resources

https://docs.pgedge.com/

https://www.pgedge.com/demo-video

https://github.com/pgedge

Author: Hari Kiran

The Risks of Not Having a Multi-Region PostgreSQL Cluster

Tue, 26 Sep 2023 20:11:00 GMT

Introduction:

In today's fast-paced digital landscape, data is at the heart of every organization's success. The PostgreSQL database system is a robust and popular choice for managing critical data, but ensuring database availability, scalability, and resilience is crucial. One strategy that can significantly mitigate risks associated with database availability is adopting a multi-region architecture. SaaS applications in particular are often implemented as single-region applications, and can benefit greatly from a multi-region approach. In this blog post, we'll delve deep into the risks of not having a multi-region strategy for your PostgreSQL database system and explore why it's a game-changer in today's data-centric world.

The Single-Region Dilemma

In the world of cloud-based databases, it's not uncommon for businesses to initially adopt a single-region setup. This means that they host their entire database infrastructure within a single geographic region provided by their chosen cloud service provider (CSP). While this approach might seem straightforward and cost-effective, it comes with significant risks and limitations that businesses must carefully consider.pgEdge Cloud is fully-distributed PostgreSQL, deployable across multiple cloud regions or data centers, with ultra high-availability, disaster recovery capabilities, data residency, compliance adherence, and business continuity. These benefits collectively help mitigate single-region deployment risks by reducing dependency on a single region and enhancing overall system resilience and flexibility.

Risks and Limitations of Single-Region Database Setup

Limited Availability: The primary drawback of a single-region setup is its limited availability. If the chosen region experiences downtime due to technical issues, maintenance, or unforeseen disasters (natural or otherwise), the entire database becomes inaccessible. This can result in a complete halt to business operations, leading to revenue loss and frustrated customers. Simply saying “we are down because our cloud provider is down” no longer is acceptable to your customers (or investors) when the outage is just one region.Data Loss: In the event of a catastrophic failure in a single-region setup, data loss is a real concern. While cloud providers implement robust backup and disaster recovery solutions, these may not always be sufficient to prevent data loss. For example, if a severe hardware failure occurs and the data center experiences data corruption, recovery may be challenging, leading to potentially irreplaceable data loss.Latency Issues: Depending on the location of the single region, users located far from that region may experience latency issues when accessing the database. Slow response times can result in a poor user experience and may deter potential customers.

Key takeaways with pgEdge

Disaster Tolerance: In the event of a catastrophic failure, such as a natural disaster or data center outage, having a copy of your database in another region provides a robust disaster recovery solution. You can quickly failover to the secondary region to minimize downtime and data loss. Using streamlined monitoring management with pgEdge toolset, and multi-master replication features, you don't need to worry about failover at all, period!Load Balancing: Multi-region setups allow for intelligent load balancing. You can route traffic to the nearest and healthiest region, optimizing performance and ensuring that each region operates at peak efficiency. Load balancing is simplified by pgEdge's out-of-box integration with pgCat - the next generation of PostgreSQL connection pooler, which supports sharding, load balancing, and mirroring.Support for Multi-Master (Active-Active) Architecture: Organizations adopting pgEdge have the option of going fully distributed, thanks to pgEdge’s built-in support for multi-master replication and delta conflict avoidance, allowing for multiple nodes to take both read and write traffic at each regional node. Alternatively the additional regional node(s) can be configured to only accept read traffic, or can simply be passive standby nodes ready for when disaster strikes.Cloud Diversification Strategy: To mitigate the “cloud concentration risk” associated with single-cloud deployment, pgEdge Cloud adopts a multi-cloud approach, optionally distributing database instances across multiple cloud service providers. It includes iEven if one CSP encounters a disruption, a pgEdgenode in another cloud can seamlessly take over, maintaining database uptime.Operational Resilience: By diversifying database hosting across CSPs, operational resilience is enhanced, safeguarding critical database services from disruptions caused by issues with a single CSP.Risk Assessment: Our thorough risk assessment at the outset takes into account the reliance on a CSP’s offerings w.r.t multi-region availability for database hosting, and ensures the implementation of PostgreSQL database administration best practices.In summary, the risk associated with single-region deployment can have significant consequences for critical PostgreSQL database applications. To address concerns related to downtime, compliance, high-availability, and scalability, it's evident that diversifying data hosting across multiple cloud providers or adopting a multi-cloud and multi-region strategy is a prudent approach to safeguard your data and applications against potential disruptions.Learn more about pgEdge Cloud or watch a live demo and presentation of “How to Make Your SaaS Resilient with Multi-region”.

Unlocking PostgreSQL 16 New Features

Wed, 20 Sep 2023 14:26:12 GMT

Here at pgEdge we are excited to see the release of PostgreSQL 16 – and even more excited at how it advances logical replication within Postgres. We are also very happy to announce that as of today pgEdge Platform already supports PostgreSQL 16, and pgEdge Cloud supports it as a deployment choice also.With the release of PostgreSQL 16, the foundation for leveraging logical replication in active-active setups has significantly improved.Multi-master replication, the ability to write to two or more PostgreSQL instances, each with a full live set of data, is an appealing solution for improving availability. However, it often introduces complexity as a tradeoff. Until now, using logical replication for bi-directional replication in core PostgreSQL caused an infinite loop as each node endlessly forwarded all transactions to other nodes (including the transactions that did not originate on it).So, what enables Multi-master in core PostgreSQL? It's the transaction loopback and origin filtering of WAL (Write-Ahead Logging) messages.Transaction loopback occurs when a transaction is replicated from the source to the target and then replicated back to the source. PostgreSQL 16 introduces a feature to address this issue. When creating a subscription, the subscriber can request that the publisher ignore transactions applied via the replication apply process, thanks to the origin messages in the WAL stream.The WAL stream contains origin messages that identify the source of the transaction, whether it originated locally or from an apply process.Logical replication in PostgreSQL is a powerful solution for replicating data changes across multiple database instances. PostgreSQL 16 enhances this feature, making bi-directional replication achievable using native replication. However, careful planning and testing are essential to maintain data integrity and consistency.Addressing previous concerns, pgEdge offers a flexible and scalable high-availability solution for PostgreSQL databases. It achieves multi-master bi-directional replication across databases and locations through the Spock extension. Spock uniquely provides a true multi-master architecture, allowing users to read and write transactions on any master node simultaneously. It captures conflict resolution events, centralizing them for easier management.For more details on pgEdge visit our blog section at: https://www.pgedge.com/blog In PostgreSQL 16, several other exciting features include:

Credit goes to my colleague, Ibrar, for seamlessly integrating this patch into pgEdge binaries across supported versions. With this enhancement, we can harness the power of standby servers in pgEdge nodes running PostgreSQL 15, achieving Ultra High-availability.

While we're on this topic, check out the blog posts from my colleague Ahsan at: https://www.pgedge.com/blog/postgresql-16-logical-replication-improvements-in-action https://www.pgedge.com/blog/postgresql-replication-and-upcoming-logical-replication-improvements-in-postgresql-16

New pg_stat_io view: Offering comprehensive I/O statistics for troubleshooting performance issues and database optimization. With this view in place, we'll be able to:

To get the latest insights on distributed PostgreSQL subscribe to the blog at https://www.pgedge.com/blog.

pglogical Rediscovered: A Fresh Approach to Logical Replication for Ultra-high Availability

Tue, 22 Aug 2023 22:26:00 GMT

Data replication is an essential aspect of modern database management systems, ensuring data availability, fault tolerance, and scalability. In the PostgreSQL world, a groundbreaking extension called Spock has emerged, transforming the way multi-master (active-active) replication is handled. Spock, based on the pglogical logical replication tool, brings in a host of new features, including conflict resolution and avoidance, asynchronous replication, and more. In this blog post, we'll explore the powerful capabilities that Spock, part of the pgEdge Platform, offers and how it addresses the challenges faced by developers and database administrators. We'll also delve into Spock’s new architecture, multi-master capabilities, security features, and the promise of high availability.

Allows selective replication of specific tables, enabling more flexible and efficient data synchronization between databases.

Unlike
, pglogical supports bi-directional replication, allowing changes to flow in both directions between source and target databases. However, without conflict resolution, this can be highly error-prone and questions the data integrity.

This allows you to apply filtering rules to determine which data changes should be replicated, providing flexibility in data synchronization.

Operates independently of the physical replication mechanisms, allowing greater flexibility and compatibility with different PostgreSQL setups and versions.

pgEdge Spock - A Leap Forward for pglogical and Multi-Master Replication for Postgres

One of the key features that sets Spock apart from pglogical is its support for asynchronous multi-master (active-active) replication. Unlike pglogical, Spock allows multiple nodes to accept writes simultaneously. This feature boosts performance and enhances fault tolerance and scalability, providing an optimal solution for demanding environments.Handling conflicts is a crucial aspect of multi-master replication. Unlike pglogical, Spock introduces conflict-free delta-apply columns, an innovative mechanism that ensures smooth and efficient conflict resolution, and handles columns that hold numeric information. With this approach, Spock will resolve to the true numeric value, significantly reducing the chances of conflicts arising in the first place, and thereby enhancing data consistency and integrity. With this approach, Spock significantly reduces the chances of conflicts arising in the first place, thereby enhancing data consistency and integrity. As I mentioned before, this is one of the features dearly missed in pglogical replication.In scenarios where conflicts do occur, Spock doesn't disappoint. It offers a robust conflict resolution mechanism that intelligently resolves conflicts without compromising data quality. Moreover, Spock comes with improved error handling, making it easier for developers and administrators to identify and address any issues that might arise during the replication process.Managing a replicated database system can be challenging. Spock simplifies this process by providing enhanced management and monitoring statistics.For reference, the following Spock metadata tables are used for real-time conflict tracking by pgEdge Cloud, a fully managed cloud service running in multiple regions across AWS, Azure, or Google Cloud.

spock.conflict_tracker

spock.resolutions

spock.local_sync_status

spock.queue

spock.lag_tracker

One of our early-stage customers operates a highly scalable web platform with users from the US and EU regions. To provide a seamless experience, they have deployed the multi-master (active-active) replication architecture using PostgreSQL with Spock. This allows them to distribute read and write operations across multiple database nodes, ensuring high availability and optimal performance. Additionally, it leverages Spock's advanced conflict resolution capabilities, so Spock intelligently identifies conflicting changes and applies sophisticated algorithms to resolve conflicts automatically.These detailed insights into replication status and performance help their analysts make informed decisions, ensuring a smooth and efficient operation. Additionally, Spock seamlessly integrates with existing PostgreSQL tools like Prometheus, enhancing the overall management experience.Spock has been undergoing rigorous performance, stability, and networking stress testing, making it a robust and reliable solution for critical deployments. Spock boasts efficient streaming of large transactions and handling distributed transactions.With the increasing demand for geographically distributed applications, Spock's support for replicating partitioned of partitioned tables comes as a game-changer. This feature enables developers to implement geo-sharding, distributing data across different geographical locations while maintaining data consistency and minimizing latency.For businesses dealing with sensitive data and privacy regulations, Spock offers a unique advantage. Users can link specific databases to a country of residence, ensuring that Personally Identifiable Information (PII) is kept within the specified region to comply with data residency requirements. Configurable PII rules (part of the metadata table) provide additional flexibility to tailor data storage policies to meet compliance needs.

Conclusion: Spock vs pglogical and where to learn more

Spock's introduction is a pglogical renaissance, and elevates PostgreSQL availability to 99.99% - the 4 9’s (now a de-facto requirement). This also heralds a new era in multi-master replication for PostgreSQL. With its support for asynchronous replication, advanced conflict resolution, and enhanced monitoring capabilities, Spock empowers developers and administrators to build highly available and scalable database architectures. Spock's stress-tested performance and support for partitioned tables offer a reliable solution for modern applications with geographically distributed data requirements. Moreover, Spock's compliance features, such as linking databases to countries of residence and configurable PII rules, ensure data privacy and regulatory compliance. For anyone seeking to elevate their database replication capabilities, Spock is undoubtedly a leap forward in the Postgres world. Check out a feature comparison here.To learn more and see a live demo, join the webinar Enhancing pgLogical with Multi-Master Features on August 30th at 11 AM ET featuring database expert and Postgres veterans Ahsan Hadi and Cady Motyka.

An Open Approach to Asynchronous Multi-master Replication With PostgreSQL

Thu, 06 Jul 2023 14:03:00 GMT

Introduction

Thanks to all that joined our Webinar An Open Approach to Asynchronous Multi-master Replication With PostgreSQL! The webinar recording and details can be found here. This blog post covers all the questions from the webinar; if you have further questions, please reach out to pgEdge at: info@pgedge.com or check out our Frequently Asked Questions page.

Installation, Requirements and Versions

pgEdge Platform requires either EL9 (RHEL/CentOS/Rocky), Amazon Linux-2023, or Ubuntu-22.04 and will currently run on PostgreSQL versions 15 and 16. It uses the community version of PostgreSQL with the exception of one small patch that enables the conflict free delta apply feature. pgEdge enhances logical replication through the Spock extension, so while you can compile your own PostgreSQL instance with this patch and extension, pgEdge platform offers you a CLI to easily install and manage PostgreSQL and Spock. As for the license for Spock, we are making all the source code we have developed for pgEdge Distributed PostgreSQL, including Spock, available under our pgEdge Community License.

Functionality

There was a great discussion in the comments about the trade off between synchronous multi-master and asynchronous multi-master. At pgEdge we wanted to focus on low latency between the application or clients and the database, in addition to high availability and partition tolerance. pgEdge nodes are eventually consistent. The time for other databases in your replication cluster to become consistent is dependent on the speed and throughput of the network links relative to the data volume to be replicated. Some other notes on pgEdge and Spock functionality:

Last update wins is an optional configuration for replication on pgEdge platform; you can choose from last update wins, first update wins, keep local, and keep remote.

Non-deterministic functions will make no difference between nodes because the resulting committed data is written out to the wall logs and replicated. Similarly, temporary and unlogged tables will not be replicated because they are not written out to the log file.

There is a function to replicate DDL functions to multiple nodes based on the replication set being used. This will not automatically add or remove items from the replication set and should be used very carefully.

Though the values of sequences can be replicated in pgEdge, it is recommended you do separate sequences on each node, and give them each a different offset to prevent conflicts (for example, n1 starts with 1, n2 starts with 2, n3 starts with 3 and they all increment by 10).

Integration

pgEdge Platform can be installed on any machine, virtual machine, or container running the operating systems listed above. Since the Spock monitoring we talked about is all within tables in the PostgreSQL database, it can easily be added as metrics to Grafana or pgWatch through a custom query against those tables. For pgEdge Cloud, you bring your own account where pgEdge will be installed and configured on virtual machines in that cloud. This allows you to use whatever other cloud services for monitoring and alerting that you’re already using against those virtual machines, the PostgreSQL database, and Spock tables. We are planning to support both Timescale & Citus. To date we have not done extensive testing, but, these extensions are included in our repository and we would love for an interested party to start testing them together.

Recovery and migration

There were a lot of questions about migrating from a traditional single node database or a database using pgLogical to a pgEdge multi-master cluster. In the coming weeks we’re going to be publishing a blog with information on how to best accomplish this. With pgEdge Platform there is no centralized service that manages the node, all decisions about conflict resolution happen on the individual node. For cluster management, data validation, and recovery of a node that drops out of the cluster, we have added some really cool features to nodeCtl and Spock. These features will be configurable for Platform but the configuration can be done automatically by pgEdge Cloud. Stay tuned for more details.

Conclusion

Thanks again to everyone that joined and participated in our first webinar. Be sure to check out our quick starts, play around with the product and the other things nodeCtl can help you with and stay tuned for more information on pgEdge Platform and pgEdge Cloud!

How to install distributed PostgreSQL with Cloudflare

Mon, 20 Feb 2023 22:33:43 GMT

A very explicit design goal for pgEdge Distributed PostgreSQL is to support distributed database access from the edge. (It may even be why we called the company pgEdge!) In this post we discuss how developers working with edge platforms like Cloudflare Workers, Fastly Compute@Edge, Vercel and similar can utilize a pgEdge cluster to significantly reduce database access times from their applications. Until pgEdge there has not been a great solution for relational database access from code deployed as edge workers or edge functions. While the edge platforms can make the static portions of applications really sing, each database access adds potentially hundreds of milliseconds to each request, and multiple requests may be needed for an individual web page. Therefore even a 3 or 5 node pgEdge cluster can dramatically improve page loads for geographically dispersed users.In additional blog posts in coming weeks we will show in detail how to integrate with several of the popular edge platforms like Cloudflare Workers and Compute@Edge. Here we want to cover the general principles to get you started.This post assumes you have already deployed a pgEdge cluster using either pgEdge Platform or pgEdge Cloud. If not check out our Getting Started guide for pgEdge Platform or use the pgEdge Cloud cluster creation UI if you are a pgEdge Cloud beta user.Here’s what your overall application architecture will look like when using (for instance) Cloudflare Workers with your pgEdge cluster:
Conceptually this will be similar when using other edge platforms like Fastly, Vercel or Netlify.Accessing pgEdge nodes from Workers or edge functionsFor most of the edge platforms all requests and responses are over HTTP/HTTPS. As a result you will need to configure PostgREST or pgrest on your pgEdge nodes. See the pgEdge documentation or contact us if you need further information on how to do this.Cloudflare Workers has a tunnel to directly access a number of different types of databases, including Postgres over port NNNN. This may be a more convenient option for some applications.Connecting to the nearest pgEdge nodeThe only additional step you need in your worker or edge function code beyond what’s needed to access other relational databases is to determine which edge data center or POP the request is being processed at and map it to the nearest pgEdge node. By convention both cloud and edge providers use the three letter IATA airport codes to identify their regions, data centers and POPs (e.g. IAD, DUB, SYD).Cloudflare Workers makes this available in the “colo” field of the incoming Request.Fastly makes this available in the FASTLY_POP environment variable.To find the closest pgEdge node to where the request is being processed, you need to:

Make the configuration details of the pgEdge nodes in your cluster available to your Worker or cloud function. You will want to identify the node location (by IATA code), the latitude and longitude of the location, and the connection string to access the database server. Use environment variables, your edge platform’s KV store, or a flat file (on say R2) to feed the cluster configuration info to your Worker or edge function.
Use a library like “geolib” to compute the nearest pgEdge node
Use the connection string for that node to connect to it.

pgEdge Cloud maintains a list of all the AWS, Azure and Google cloud regions with their IATA codes and approximate physical coordinates. Send your SQL query, or make an application specific PostgREST API callThis is the easy part, just like accessing other relational databases.Cloudflare has an excellent blog post discussing how to build applications with PostgreSQL and Cloudflare Workers. Basically all of this is applicable to pgEdge, subject to what you see written above.Stay tuned for more edge integration posts!Over the course of the pgEdge beta period we will be rolling out tighter integration with several leading edge platforms – stay tuned. And as mentioned above, in coming weeks we will provide more detailed posts addressing each of these platforms, along with example code to get you going even more quickly.