Frequently Asked Questions

We currently support up to 7 database nodes in a cluster. However for many applications we are finding just three database nodes, placed in appropriate locations relative to incoming user traffic, can greatly improve data latency experienced by application users. For example, locating nodes on each of the US east and west coasts plus a location in Europe is a good choice for SaaS, e-commerce or general web applications servicing North American and European users.

pgEdge Platform can scale to a higher number of nodes using a hierarchical replication architecture to keep replication traffic between nodes at a manageable level. This is not currently supported for production usage – please contact pgEdge support to determine if your application needs this capability.

Yes! We have designed pgEdge Distributed PostgreSQL to support placement of nodes across global networks. In particular you can have pgEdge nodes running in geographically disparate cloud regions across your cloud provider’s network.

pgEdge is a multi-master distributed database system built on standard PostgreSQL and designed for low latency, high availability and seamless failovers. It relies on Postgres to guarantee ACID properties at the node level to clients. In a distributed cluster — that may span multiple cloud regions or datacenters — pgEdge offers eventual consistency using a configurable policy (e.g. last-writer-wins) for conflict resolution, along with conflict-free delta apply columns for running sum fields. This allows for independent, concurrent and eventually consistent updates across multiple nodes.

When workloads are partitioned optimally, customers using pgEdge can enjoy low latency and high availability without worrying about data consistency. However, it is essential to note that pgEdge is an AP system according to the CAP theorem (Wikipedia and Gilbert et al.) that prioritizes availability and partition tolerance over strong consistency. Our support team can work with you to plan and optimize your workload to meet your application’s availability and consistency requirements in a distributed architecture

Yes. You can configure synchronous read-only nodes in availability zones within the same region for local within-region failover.

Yes!  Please see this blog post to see how to use pgEdge with platforms like Cloudflare Workers.

To achieve the maximum latency benefit from pgEdge you will want to replicate your application logic to be resident in each of the same cloud regions or data centers where you are placing pgEdge database nodes. 

You will want to use automation to ensure your application code stack and infrastructure is configured identically in each region.  A tool like Terraform or CloudFormation for cloud infrastructure and CI/CD tooling to manage code deployments are highly recommended. pgEdge Cloud ensures the database infrastructure and software are deployed securely and identically across your chosen regions.  

If you are using an edge platform like Cloudflare Workers you do not need to worry about this; your application logic is already available across the edge network you are utilizing.

Spock is a pgEdge-developed PostgreSQL standard extension that supports multi-active (multi-master) logical replication, making it possible for pgEdge Distributed PostgreSQL to be fully distributed with reads and writes taking place at any node.

We are making the Spock code available under the pgEdge Community License.  You can find the Spock source code on Github.

The Spock conflict resolution algorithm on its own does not correctly handle “running sum” columns for items such as inventory and account balances.  pgEdge supports conflict-free delta apply columns that use a delta application technique to ensure that for a potentially conflicting transaction the deltas at each node are captured and replicated to ensure a correct end result.   This delivers the same behavior as Conflict-free Replication Data Types (CRDTs) for running sum columns in certain other distributed database systems. This simpler approach for a common use case reduces programming complexities associated with CRDT.  More advanced capabilities for implementing other Conflict-free Replication Data Types (CRDTs) are (or will be) available via user-defined functions; please contact pgEdge support for more information.

pgEdge is used by a number of SaaS, financial services and technology companies, along with organizations working on US national security projects.

pgEdge is 100% based on standard PostgreSQL, with one exception noted below. 

The one exception is a single small patch to PostgreSQL to support Spock’s conflict-free delta apply columns feature.   We are making this available under the standard PostgreSQL license and offering it to the community for possible inclusion in future versions of Postgres (which may or may not happen).

We currently support v15, v16 and v17 for both pgEdge Cloud and pgEdge Platform.

Our experience with many PostgreSQL workloads and early experience with pgEdge Distributed PostgreSQL suggests that most applications are relatively “conflict free” and do not require significant changes – some require no changes at all, especially if schemas are well designed.

If during testing a workload does generate significant conflicts our support team works with the customer to suggest schema changes, usually minor.   This may impact some of the application code, but generally not in a substantial way.

We are making all the source code we have developed for pgEdge Distributed PostgreSQL, including Spock, available under our pgEdge Community License. This license is identical to the Confluent Community License (except for company name and venue).

The one exception is one small patch to PostgreSQL to support Spock’s conflict avoidance/delta application feature.   We are making this available under the standard PostgreSQL license and offering it to the community for possible inclusion in future versions of Postgres.

We are huge fans of open source, and we have several decades of experience contributing to and working with the PostgreSQL community.    While our strong inclination is to make all our source code available under an Apache or PostgreSQL license, like many open source companies we need to guard against major cloud providers or other competitors simply standing up our code in the cloud and offering a service that competes with pgEdge Cloud.

As a user or customer of pgEdge Distributed PostgreSQL you may use the code for any purpose, except for the purpose of making available any software-as-a-service, platform-as-a-service, infrastructure-as-a-service or other similar online service that competes with pgEdge products or services that provide the Software.

The source code for all the components of pgEdge Distributed PostgreSQL is available on Github. With pgEdge Platform we provide tested and integrated binaries on a range of pre-validated and supported environments, in addition to providing support, timely access to fixes and early access to new features. It is a part of our business model to be paid for this level of support in exchange for the value provided.  Anyone is welcome to take our open source components and assemble and integrate them for their own use.

We currently support AWS, Azure, Google Cloud Platform and Equinix Metal. pgEdge Platform may run in other cloud providers – please contact pgEdge Support for details, and to determine if we can offer support for them.

We believe the current SaaS model where the vendor is responsible for paying for and managing cloud infrastructure doesn’t work well at scale for either customers or the vendors themselves.  Having vendors resell cloud infrastructure is more expensive for everyone, and presents security risks and challenges to enterprise security teams who need assurances about the safety of SaaS vendor cloud configurations.  (Some of us spent the last few years in the cloud security world.  The misconfigurations we saw in a lot of cases were rather disturbing!)

Using a BYO account model benefits the customer by leveraging the substantial enterprise discounts available to larger cloud users.   The infrastructure usage driven by pgEdge will factor into future enterprise discounts from the cloud provider(s).  And most importantly, since the deployed infrastructure is running in the customer’s own cloud account, security teams and their security tooling (e.g. Wiz, Orca, Palo Alto Prisma, etc) have full access.

Yes.  In the coming months we plan on announcing a “Developer Edition” in 2H 2023.  This will support a smooth and easy getting started flow that will run in cloud infrastructure managed by pgEdge.  This will support development and evaluation purposes, as well as small production projects. Larger production databases should be deployed in the customer’s own account.

We are currently making preparations to begin a SOC-2 certification process in Q1 2024.

pgEdge Cloud is currently still in beta as we continue to refine it and add new features. However pgEdge Cloud runs on top of pgEdge Platform, which is generally available, and as such we are able to support customers going into production on pgEdge Cloud.

Yes, at the pgEdge Platform download page. The free download can be used for development and evaluation purposes. For production usage or access to enterprise-grade support we sell subscriptions for pgEdge Platform Enterprise Edition.

We currently support AWS, Azure, Google Cloud Platform and Equinix Metal. pgEdge Platform may run in other cloud providers – please contact pgEdge Support for details, and to determine if we can offer support for them.

pgEdge Platform is now generally available. pgEdge provides support for production usage via the pgEdge Platform Enterprise Edition.

Pricing for pgEdge Cloud is competitive with non-distributed DBaaS (Database-as-a-Service) offerings. Please email [email protected] for details.

Pricing for pgEdge Platform Enterprise Edition is competitive with subscriptions for comparable products based on or derived from open source software. Please email [email protected] for details.