Frequently Asked Questions

pgEdge is used by an array of SaaS, AI, financial services and technology companies, along with multiple government agencies in the US Government and Europe.

Spock is a pgEdge-developed PostgreSQL extension that supports asynchronous multi-master (active-active) logical replication, making it possible for pgEdge Distributed Postgres to be fully distributed with reads and writes taking place at any node. It is installed by default as part of pgEdge Enterprise Postgres, so that your installation is Distributed-Ready, providing an easy upgrade path to pgEdge Distributed Postgres.

Yes. Spock is a fully open source project under the PostgreSQL License. The source code is publicly available on GitHub, with no restrictions beyond those of the standard PostgreSQL community license.

Yes. pgEdge has achieved SOC 2 Type II certification across all of its products, including pgEdge Distributed Postgres and pgEdge Enterprise Postgres. This certification confirms that our security, availability, and operational processes meet rigorous industry standards, and reflects our commitment to protecting customer data and maintaining trust across all deployment models.

Yes. All pgEdge products and components, including pgEdge Distributed Postgres, pgEdge Enterprise, and supporting extensions such as Spock, are delivered with SBOMs (Software Bills of Materials). These SBOMs provide transparency into the open source and third-party components included in each release, supporting compliance, security auditing, and supply chain risk management.

pgEdge is built 100% on standard PostgreSQL, with a minimal set of targeted patches to enable advanced replication capabilities required by pgEdge Distributed Postgres, such as support for conflict-free delta apply columns in Spock.

These patches are fully open source and licensed under the standard PostgreSQL license. They are included by default in pgEdge Enterprise, making it “Distributed-Ready” and providing a seamless upgrade path to pgEdge Distributed when you’re ready to enable write-anywhere, multi-region replication.

For pgEdge Enterprise Postgres (single-cluster, self-hosted), we currently support PostgreSQL versions 16 and 17.

For pgEdge Distributed Postgres, we currently support PostgreSQL v15, v16, and v17.

For pgEdge Enterprise Postgres, no changes are required. It is a drop-in replacement for standard PostgreSQL and is fully compatible with your existing applications and database schemas.

For pgEdge Distributed Postgres, most applications work with little or no modification, especially when the schema design avoids write conflicts. Our experience across a wide range of PostgreSQL workloads shows that many real-world applications are naturally “conflict free.”

However, distributed replication does require a few key schema considerations:

• All replicated tables must have a primary key. Logical replication depends on primary keys to identify and synchronize changes across nodes.

• Standard PostgreSQL sequences do not work correctly in a distributed, multi-master environment, as they are not replicated and can lead to ID collisions. To solve this, pgEdge includes a built-in Snowflake Sequences extension, which fully replaces the standard SEQUENCE mechanism.  The pgEdge Snowflake extension generates globally unique, time-sortable 64-bit integer IDs using the widely adopted Snowflake ID algorithm. Each ID encodes a timestamp (epoch), node ID, and sequence counter into a single packed BIGINT. It includes drop-in replacements for nextval() and currval(), as well as helper functions to extract the embedded metadata (timestamp, node ID, and local sequence value) from each generated ID. This solution makes it easy to use surrogate keys in distributed schemas without needing UUIDs or custom logic, and without sacrificing performance or sortability.

If any schema or application changes are needed to optimize for distribution, our team is available to assist. These changes are typically minimal and straightforward.

All publicly available pgEdge-developed source code is now fully open source and licensed under the standard PostgreSQL License. This includes Spock, our advanced logical replication extension. We’ve adopted the same permissive license used by PostgreSQL itself to encourage openness, transparency, and community collaboration.

pgEdge includes a minimal set of patches to the PostgreSQL core to support advanced conflict-avoidance and delta-apply functionality in Spock. This patch is also licensed under the PostgreSQL License and has been submitted to the community for potential inclusion in future versions of PostgreSQL.

Both pgEdge Enterprise Postgres and pgEdge Distributed Postgres are fully open source. All pgEdge-developed runtime components, including Spock and the necessary PostgreSQL patches, are licensed under the standard PostgreSQL License and available on GitHub. Anyone is free to use, modify, and deploy them independently at no cost.

We charge for production usage when customers choose to rely on our commercial offering, which delivers significant additional value beyond the open source components. This includes:

• Pre-built and tested binaries for supported environments

• System-level packaging, configuration, and deployment tooling

• Access to production-grade support and SLAs

• Timely delivery of bug fixes and security patches

• Early access to new features and improvements

This commercial model allows us to fund ongoing development while giving users the flexibility to choose between self-managing the open source components or relying on our supported distribution for production needs.

pgEdge Enterprise Postgres is a hardened, enterprise-grade distribution of PostgreSQL, built and packaged by pgEdge. It includes performance, manageability, and replication enhancements, enterprise-ready extensions, and an easy upgrade path to pgEdge’s distributed write-anywhere architecture.

pgEdge Enterprise Postgres is a self-hosted, single-cluster PostgreSQL distribution designed for organizations that want enterprise-class PostgreSQL with commercial support, advanced extensions, and full compatibility—without the complexity of a distributed architecture.

In contrast, pgEdge Distributed Postgres is a fully distributed, multi-master PostgreSQL product with built-in multi-master replication, high availability, and support for active-active deployments across regions.

pgEdge Enterprise Postgres includes everything needed to run PostgreSQL in production and is “Distributed-Ready” - you can enable Spock at any time to upgrade to a fully distributed setup with no need to reinstall or reconfigure your database foundation.

The package includes PostgreSQL 16 & 17 with pgEdge patches, plus key enterprise extensions such as Spock, pgAudit, pgBackRest, pgBouncer, PostGIS, pgVector, LOLOR, and the Snowflake sequence extension. All packages are built, tested, and provided via a secure repository for RHEL, Rocky Linux, AlmaLinux, Debian and Ubuntu.

No. Spock is included but disabled by default in the Enterprise package. Customers can enable it later to add multi-master, write-anywhere capabilities without changing their database distribution.

pgEdge Enterprise Postgres supports RHEL 9 & 10, Rocky Linux 9 & 10, and compatible distributions on x86_64 and aarch64 (ARM) architectures. It also supports Debian 11, 12 and 13 (AMD and ARM) as well as Ubuntu 22.04 and 24.04 (AMD and ARM).

A pgEdge Enterprise Postgres subscription includes 24x7x365 support from our PostgreSQL experts, with defined SLAs for issue response and resolution. Optional dedicated Forward Deployed Engineer services are also available.

The Enterprise Postgres packages are available and supported as part of a paid subscription. This includes the software, tested builds, security updates, and support. Many included extensions are open source, but the bundled build and packaging are pgEdge-maintained.

Yes. Our packages are designed to be drop-in replacements for community PostgreSQL. Migration is supported from previous community versions with standard PostgreSQL upgrade methods. Migration assistance is available as part of the Support Subscription.

Yes! We have designed pgEdge Distributed Postgres 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 between nodes using a configurable policy (e.g. last-writer-wins) for conflict resolution, along with conflict-free delta apply columns (i.e. CRDTs) 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 compromising the practical consistency needs of their applications. According to the PACELC theorem, which expands on the CAP theorem, distributed systems must make trade-offs not only if there is a Partition (P), choosing between Availability (A) and Consistency (C), but also else (E), during normal operation, between Latency (L) and Consistency (C).

pgEdge is designed to prioritize availability and low latency, making it well suited for geo-distributed deployments that require responsiveness and regional fault tolerance. While this approach favors eventual consistency during partitions and emphasizes fast response times during normal conditions, pgEdge includes conflict-resolution and delta-apply mechanisms to preserve logical correctness. Our support team can assist in optimizing your workload and schema design to meet the specific availability, latency, and consistency needs of your application.

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

Yes! Please see the following resources:

• Blog post to see how to use pgEdge with platforms like Cloudflare Workers.

• Video and download of using pgEdge Distributed Postgres with Akamai Cloud.

For pgEdge Distributed Postgres: VM Edition and pgEdge Distributed Postgres: Cloud Edition, to achieve the maximum latency benefit you will want to replicate your application logic so it is resident in each of the same cloud regions or data centers where you are placing pgEdge database nodes. Use automation to ensure your application code stack and infrastructure are configured identically in each region. Tools such as Terraform or CloudFormation for infrastructure and CI/CD pipelines for code deployments are highly recommended. pgEdge Distributed Postgres: Cloud Edition ensures the database infrastructure and software are deployed securely and identically across your chosen regions. If you are using an edge platform such as Cloudflare Workers, your application logic is already available across the edge network you are utilizing.

Standard logical replication by itself does not correctly handle “running sum” columns for items such as inventory and account balances.  pgEdge Distributed Postgres 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 CRDTs. More advanced capabilities for implementing other Conflict-free Replication Data Types will be available via user-defined functions in a future release; please contact pgEdge support for more information.

Yes. pgEdge Distributed Postgres is available as a free download at https://www.pgedge.com/download. It can be used at no cost for development, testing, and evaluation purposes.

For production deployments, we offer commercial subscriptions that include enterprise support, certified builds, security updates, and access to new features. This ensures a stable and secure experience when running pgEdge in mission-critical environments.

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 Distributed Postgres 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.

It delivers enterprise-grade Postgres infrastructure for Agentic AI applications in environments with strict requirements around high availability, security, data sovereignty, and global deployment.  The pgEdge AI Toolkit is the first and only solution that provides the ability to move from prototype into production for both new applications as well as an existing Postgres database. Other vendors on the market offer limited options, focusing on creating prototypes that are not in production or enterprise-grade, or only allow the building of net-new apps. 

The pgEdge Agentic AI Toolkit components are fully open-source under the PostgreSQL License. pgEdge takes a different approach by letting teams run Agentic AI on standard, fully open-source Postgres. Organizations gain enterprise-grade Postgres and Agentic AI capabilities without proprietary lock-in, while staying aligned with the broader PostgreSQL community. 

As with other pgEdge Postgres products the pgEdge Agentic AI Toolkit for Postgres is fully open source via the Postgres license.  The pgEdge Agentic AI Toolkit for Postgres is available for free to all Postgres users. pgEdge customers with paid subscriptions for pgEdge Enterprise Postgres or pgEdge Distributed Postgres receive support at no extra cost. Curious about giving it a try, but don’t need the enterprise support package? You’re welcome to self-host! Check it out on GitHub

The pgEdge Postgres MCP Server is a production-ready Model Context Protocol (MCP) implementation that enables AI assistants and code generators to interact with PostgreSQL databases through natural language. It provides read-only SQL query execution, PostgreSQL statistics access, advanced tools including hybrid search (BM25+MMR), embedding generation, guided workflows for semantic search setup and database exploration, and comprehensive security with TLS support and token authentication.

Unlike basic MCP servers that only expose schema information, pgEdge's implementation provides a complete toolkit for database interaction. It includes a production chat client with prompt caching (achieving 90% cost reduction), a modern React-based web interface with AI-powered chat for natural language database interaction, complete Docker Compose deployment, and hot reload of authentication files without server restart. The server works with any standard PostgreSQL (v14 and newer) installation - community versions, Amazon RDS, or pgEdge Distributed Postgres.

The pgEdge Postgres MCP Server makes PostgreSQL "AI-native" by providing LLMs with deep understanding of database schemas, relationships, performance metrics, and query capabilities—all while maintaining production-grade security and read-only protection.

The pgEdge RAG Server is an API server that retrieves relevant content from PostgreSQL and sends it to Large Language Models for AI-powered responses. It provides multiple RAG pipelines with configurable embedding and LLM providers, hybrid search combining vector similarity and BM25 text matching, support for OpenAI, Anthropic, Voyage, and Ollama LLM providers, and token budget management to control costs.

When queries arrive, the RAG Server uses hybrid search that combines vector similarity (catching semantically related content) with BM25 keyword matching (ensuring you don't miss obvious keyword matches), and this combination tends to give better results than either method alone. Configure pipelines through a YAML file that specifies which database tables to search, which embedding model to use, and which LLM generates responses.

Key Features: Hybrid semantic + keyword search, multi-pipeline support for different use cases, flexible LLM support (cloud and local models), token budget cost controls, and streaming responses. Written in Go with TLS support for production deployment.

Works seamlessly with pgEdge Vectorizer (automatic embedding maintenance) and pgEdge Docloader (document ingestion) for a complete PostgreSQL-native RAG pipeline.

The pgEdge Vectorizer is a PostgreSQL extension that automates the creation and maintenance of vector embeddings for semantic search applications. Rather than requiring external services or complex data pipelines, it runs inside PostgreSQL as an extension, automatically chunking text and queuing it for embedding when you insert or update documents through triggers, while background workers process the queue asynchronously by calling your chosen embedding API and storing the results.

With a single SQL command, you can enable automatic vectorization on any table. The extension creates a chunks table to store the text segments, sets up triggers to automatically chunk new or updated content, and creates an HNSW vector index for fast similarity search. It supports multiple embedding providers including OpenAI, Voyage AI, and local models via Ollama for complete privacy and zero usage costs.

The Vectorizer is designed for developers who want to add semantic search capabilities to their PostgreSQL applications without managing separate vector databases or complex infrastructure. It handles chunking strategies (token-based, recursive character splitting), manages embedding queues with automatic retry logic, and provides built-in functions for generating query embeddings—all while keeping your documents, embeddings, and application data together in PostgreSQL with full transactional guarantees.

pgEdge Document Loader is a command-line tool that automatically converts documentation from multiple formats (HTML, Markdown, reStructuredText, and SGML/DocBook) into clean Markdown and loads it directly into PostgreSQL. It extracts metadata like titles, filenames, and timestamps, supports flexible input via single files, directories, or glob patterns including recursive matching, and handles updates transactionally with automatic rollback on errors github.

The tool is designed as the first step in building RAG (Retrieval-Augmented Generation) pipelines, preparing your documentation for vectorization and semantic search. Whether you're loading technical documentation, knowledge bases, or content repositories, Document Loader handles format conversion and database insertion in a single command, with support for custom metadata columns and configurable mappings to match your schema.

These three components form a complete end-to-end RAG (Retrieval-Augmented Generation) pipeline that runs entirely on PostgreSQL infrastructure:

Step 1: Document Loader - Ingestion Document Loader converts your documentation from multiple formats (HTML, Markdown, reStructuredText, SGML/DocBook) into clean Markdown and loads it into PostgreSQL with extracted metadata. This creates a documents table containing your content in a consistent, searchable format.

Step 2: Vectorizer - Automatic Embedding Generation pgEdge Vectorizer creates a chunks table to store text segments, sets up triggers to automatically chunk new or updated content, and enables fast similarity search. Background workers process the queue asynchronously, calling your chosen embedding API (OpenAI, Voyage AI, or local Ollama) and storing the vector embeddings, no manual intervention required.

Step 3: RAG Server - Query & Response Generation The RAG Server sits between your application and the LLM, handling retrieval using hybrid search that combines vector similarity with BM25 keyword matching. When a query comes in, it retrieves the most relevant chunks from your vectorized content, embeds the query using the same model, and sends the context to your chosen LLM (OpenAI, Anthropic Claude, or Ollama) for response generation.

The Complete Workflow:

1. Run Document Loader to ingest docs → stored in PostgreSQL

2. Enable Vectorizer on the table → automatic chunking and embedding

3. Deploy RAG Server with your configuration → instant semantic search API

4. Update docs anytime → Vectorizer automatically maintains embeddings

5. Query via RAG Server API → get AI-powered answers grounded in your documentation

The entire pipeline runs on PostgreSQL plus a single Go binary. No message queues, no separate vector databases, no complex orchestration. Just SQL and HTTP. Your documents, embeddings, and application data live together with full transactional guarantees and the operational tooling you already know.

The Toolkit supports a range of models ranging from locally hosted Ollama to internet accessible frontier models such as Claude and OpenAI.

You can begin with one database and expand to multi-region deployments, while staying in control of security, compliance, and where your data lives. pgEdge takes your agentic applications from development through mission-critical production deployment, with flexible options for single-node or globally distributed architectures.

We currently support AWS, Azure, and Google Cloud Platform.

If you have a large potential deployment and need support for a different cloud provider, please reach out—we’re happy to discuss additional options based on customer demand.

We believe the traditional SaaS model, where the vendor provisions and manages cloud infrastructure, does not scale well for customers or vendors. When vendors resell cloud infrastructure, it often results in higher costs and introduces security challenges. Enterprise security teams frequently need visibility and assurance over the configuration of cloud environments, and this is difficult to achieve with fully vendor-managed SaaS.

Using a BYO account model provides several key advantages:

• Lower cost. Customers can take advantage of their existing enterprise discounts and committed cloud spend.

• Stronger security. The infrastructure runs entirely within the customer’s own cloud account, allowing security teams to apply their own controls and monitoring.

• Better compliance and control. Internal tools such as Wiz, Orca, and Palo Alto Prisma can be used without restriction, and governance requirements are easier to meet.

Our team includes professionals with extensive experience in cloud security. Based on what we have seen across the industry, allowing customers to maintain full ownership of their infrastructure is the most secure and scalable model.

pgEdge supports both container-based and Kubernetes-based deployments:

• For Kubernetes environments, we provide a Helm chart built for the CloudNativePG operator, enabling declarative deployment and orchestration of pgEdge database instances in single-region or multi-region setups.

• In order to make it easier to operate pgEdge in CloudNativePG, and to support other integrations, we’re releasing a new container image built from our pgEdge Enterprise Postgres packages with support for Postgres 16+. This approach means that you can utilize a single set of images across your Postgres deployments, whether they be in a single region, or distributed with spock’s multi-master replication. These images are published on the Github Container Registry as pgedge/pgedge-postgres at https://github.com/pgEdge/postgres-images/pkgs/container/pgedge-postgres also include optional docker-compose scripts for deploying:

  • pgEdge Enterprise Postgres (non-distributed)

  • pgEdge Distributed Postgres (multi-region active-active)

The pgEdge Helm chart simplifies the deployment of both pgEdge Enterprise Postgres and pgEdge Distributed Postgres in Kubernetes. It leverages the CloudNativePG operator to manage cluster lifecycle, high availability, failover, and replication, with best-practice configuration baked in for fast and secure deployment.

CloudNativePG is the de facto standard for running PostgreSQL on Kubernetes. It is a CNCF Sandbox project with a Kubernetes-native architecture, built and maintained by Postgres experts. It offers:

• Automated failover and high availability

• Integrated backup and recovery

• Declarative configuration

• Cloud-neutral deployment

• Seamless integration with pgEdge’s multi-master Spock extension

The chart deploys:

• Postgres 16, 17, and 18 via pgEdge Enterprise Postgres Images.

• Flexible deployment options for both single-region and multi-region deployments

  • Deploy pgEdge Enterprise Postgres in a single region with optional standby replicas.

  • Deploy pgEdge Distributed Postgres across multiple regions with Spock multi-master replication.

• Configuring Spock replication configuration across all nodes during helm install and upgrade processes.

• Best practice configuration defaults for deploying pgEdge Distributed Postgres in Kubernetes.

• Extending / overriding configuration for CloudNativePG across all nodes, or on specific nodes.

• Configuring standby instances with automatic failover, leveraging Spock's delayed feedback and failover slots worker to maintain active-active replication across failovers and promotions.

• Adding pgEdge nodes using Spock or CloudNativePG's bootstrap capabilities to synchronize data from existing nodes or backups.

• Performing Postgres major and minor version upgrades.

• Client certificate authentication for managed users, including the pgedge replication user.

• Configuration options to support deployments across multiple Kubernetes clusters.

Yes. The pgEdge Helm chart automatically provisions the required CloudNativePG Cluster resources, along with supporting Kubernetes objects. You only need to ensure that the CloudNativePG and cert-manager operators are already installed in your environment. This approach allows pgEdge to handle database deployment declaratively while leaving operator installation and lifecycle management under your control.

You can fully customize the created Cluster resources through Helm values, including settings such as the number of replicas, storage configuration, resource limits, and connection parameters.

Before installing pgEdge using the Helm chart, ensure the following components are already in place:

1. CloudNativePG Operator – Installed and running in the target namespace.

2. cert-manager – Installed and configured to issue TLS certificates.

With these prerequisites met, you can install the pgEdge Helm chart and configure your deployment using Helm values.

Yes. pgEdge Distributed Postgres is designed for multi-cloud, multi-region deployments. Using cross-cluster DNS (e.g., via Cilium or Submariner) and synchronized certificates, you can operate fully active-active Postgres clusters across any number of Kubernetes environments.

pgEdge Control Plane is a distributed application that provides a declarative API for defining, deploying, and updating Postgres databases across multiple hosts. It simplifies database management by enabling consistent operations whether you're running single region or globally distributed deployments.  Deploy and operate pgEdge Enterprise Postgres and pgEdge Distributed Postgres on virtual machines or bare metal hosts using pgEdge Control Plane

Control Plane uses a declarative API approach that makes scaling from single-region to multi-region seamless. You define your desired database state once, and Control Plane handles the implementation details.

When you're ready to go distributed, you simply update your database configuration to add additional regions and enable Spock active-active replication—all without rebuilding your infrastructure or modifying your application code. Control Plane automatically manages the replication configuration, DDL synchronization across nodes, and ensures consistent deployment across all regions.

The "zero downtime add node" capability means you can expand your cluster to new geographic regions while your applications continue running without interruption. This gives you the flexibility to start simple with a single region deployment and scale globally as your business requirements evolve, all while maintaining operational consistency.

Control Plane is designed specifically for VM and bare metal deployments, offering several advantages for organizations that aren't using Kubernetes:

When Control Plane is the better choice:

• Bare metal or VM-first environments - Many enterprises have significant investments in existing VM infrastructure or run bare metal for performance reasons

• Simpler operational model - No need to learn Kubernetes, maintain clusters, or deal with container orchestration complexity

• Direct host access - Full control over the underlying operating system and hardware configuration

• Legacy integration - Easier integration with existing monitoring, backup, and operational tooling designed for traditional infrastructure

• Hybrid deployments - Mix on-premises bare metal with cloud VMs seamlessly

How they're similar:

• Both use declarative APIs to define desired state

• Both provide automated deployment and lifecycle management

• Both support multi-region distributed deployments with pgEdge Distributed Postgres

• Both include integrated backup/restore capabilities

• Both offer zero downtime operations for scaling

When Kubernetes might be better:

• You're already deeply invested in Kubernetes infrastructure

• You need advanced container orchestration features

• Your entire stack is containerized

• You want to leverage Kubernetes-native monitoring and GitOps workflows

The good news: pgEdge supports both! You can use Control Plane for VM/bare metal deployments and pgEdge Containers with CloudNativePG for Kubernetes deployments, giving you flexibility across your entire infrastructure.

Yes! Control Plane explicitly supports deploying multiple PostgreSQL databases on the same host, which is perfect for development, testing, and staging environments where you want to maximize resource utilization.

Common use cases:

• Clone production for testing - Create multiple copies of production databases on development hosts for parallel testing of different features

• Multi-tenant development - Give each developer their own isolated database instance on shared infrastructure

• CI/CD pipelines - Spin up temporary test databases for automated testing, then tear them down

• Staging environments - Run multiple versions of your application stack on cost-effective shared hosts

How it works: Control Plane manages the isolation and resource allocation across databases on the same host. Each database instance gets:

• Its own PostgreSQL process and data directory

• Dedicated port assignments

• Separate configuration management

• Independent backup/restore operations

• Isolated extension management

Production considerations: While multi-database hosting is excellent for dev/test, production deployments typically dedicate hosts to single databases or use fewer, larger instances to ensure predictable performance and resource isolation. Control Plane gives you the flexibility to choose the right architecture for each environment.

Control Plane currently supports PostgreSQL 16, 17, and 18, giving you access to the latest Postgres features and performance improvements.

Included enterprise-grade extensions:

• Spock - Multi-master logical replication for distributed deployments

• LOLOR - Large object logical replication for media and file storage

• Snowflake - Cluster-wide unique sequence generation for distributed systems

• pgAudit - Comprehensive database auditing for compliance

• PostGIS - Spatial and geographic data types and functions

• pgVector - Vector similarity search for AI/ML applications

• pgBackRest - Enterprise backup and recovery solution

Yes. The Control Plane is fully open source and released under the PostgreSQL License, one of the most permissive open source licenses available. It is purpose-built to manage and orchestrate both single-node and distributed Postgres databases, with or without read replicas, providing flexible lifecycle management for a wide range of deployment architectures.

pgEdge Enterprise Postgres is our single-cluster, non-Distributed Postgres distribution with enterprise-grade extensions and full commercial support. It is ideal for organizations that want a supported PostgreSQL deployment without the complexity of geo-distribution, while maintaining the option to upgrade to distributed later. Subscriptions include support, updates, and integration with pgEdge tooling. Please email [email protected] for detailed pricing.

pgEdge Distributed VM Edition is free to download and use for development and evaluation. For production deployments, we offer subscription plans that include enterprise support, certified binaries, updates, and access to advanced features. Pricing is competitive with other commercially supported PostgreSQL-based offerings. Please reach out to [email protected] for more information.

Pricing for pgEdge Distributed Postgres:Cloud Edition is competitive with other managed PostgreSQL DBaaS offerings, while providing the added benefits of distributed, multi-region, active-active deployment. Please contact us at [email protected] for current pricing and deployment options.