Frequently Asked Questions

During the beta period we support up to 5 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.

We will be supporting a larger number of nodes in future, once the pgEdge Platform beta period is over. Having said that, we know it will be desirable to keep the node count relatively low to keep replication traffic between nodes at a manageable level.

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 allows both read and write operations to take place at any database node in a geographically distributed cluster. Clients speaking to the same Postgres node see ACID properties with regard to each other. At the wider scale -- spanning multiple cloud regions or data centers -- pgEdge makes use of eventual consistency with conflict resolution and delta conflict avoidance (for running sum fields) to allow for concurrent, independent, low-latency updates. 

We are working with leading distributed systems consultants during the beta period to test and refine the claims we make with regard to overall system safety. We will have more to say about this as we approach the end of the beta period.

Yes.

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. 

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 balance” columns for items such as inventory and account balances.  The pgEdge conflict avoidance mechanism uses a delta application technique to ensure that for each 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 (CRDT) 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 (CRDT) are (or will be) available via user-defined functions; please contact pgEdge support for more information.

Yes!  We have been working with a number of customers while in stealth mode, prior to our public launch.

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 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 (which may or may not happen).

We currently support v15 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.

We currently support AWS and Azure. We plan to add support for Google Cloud Platform in 2H 2023.  (Please reach out to us if you have a large potential pgEdge project and need it sooner!)

We are working with certain select customers as we refine the pgEdge Cloud offering in coming months. Other potential customers are being placed on a waitlist. If you have an application that you believe is a good fit for pgEdge Cloud please reach out.

We believe the current SaaS model where the vendor is responsible for paying for and managing cloud infrastructure is broken, and doesn’t work well for customers or the vendors themselves.  Having vendors resell cloud infrastructure is more expensive for everyone, and it also 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. Snyk Cloud, Palo Alto Prisma, etc) have full access.

Yes.  We plan on having a “Developer Edition” in 2H 2023.  This will support a smooth and easy getting started flow that will run in infrastructure managed by pgEdge.  However this will be for development purposes only.   Production databases will still be deployed in the customer’s own account.

We are currently making preparations to begin a SOC-2 certification within a few months of our beta launch.

Yes, at the pgEdge Platform download page.

We currently support AWS, Azure and Google Cloud Platform. pgEdge Platform may run in other cloud providers, but we are not providing support services for them at this time.

We are not supporting production usage until the pgEdge Platform beta period ends.  Platform users may after their own testing choose to put pgEdge databases into production. We will advise pgEdge Cloud users individually when we can support their databases going into production, which may be before the pgEdge Cloud beta period ends.

Yes.   Please see our Enterprise Support Subscriptions page for details.

We are offering a Development Support Subscription, which will automatically transition to an Enterprise Support Subscription when the pgEdge Platform beta ends.

We are currently targeting Q3 2023.

We are currently targeting Q3 2023.  The pgEdge Cloud private beta may be on a different schedule to the pgEdge Platform beta.

Pricing for pgEdge Cloud is competitive with non-distributed DBaaS offerings in the range of $150-$180 per vCPU/month. Please email [email protected] for details.

Pricing for Enterprise Support Subscriptions is competitive with support subscriptions for comparable open source products. Please email [email protected] for details.