pgedge_postgres

pssst... we're 100% open source under the PostgreSQL license, with active-active multi-master replication for any topology from single-region HA to write-anywhere global. :-) try it out on the Downloads page on our site https://www.pgedge.com/download/enterprise-postgres for secure downloads, or check out Spock on GitHub (https://github.com/pgEdge/spock) and the Active Consistency Engine (https://github.com/pgedge/ace) to integrate the extension & tool yourself. Answers to common questions in our FAQ: https://www.pgedge.com/resources/faq#pgedge-distributed-post...

Hi! From the presenter,

The PG 18 features that i am presenting don't directly address vector search; however asynchronous I/O can impact large vector index scan, RETURNING enhancements are useful for tracking vector insertion and updates, and generated column replication could replicate calculated embedding across distributed nodes. PostgreSQL 18 itself don't have native vector search improvements but the pgvector extension has been making significant strides in PostgreSQL 18 performance improvements which can indirectly benefit vector workloads....

We listened to customers as they refined their AI strategies in response to the rapid evolution of LLMs, Agentic AI and integration technologies such as the Model Context Protocol (MCP), and as we did so a few things stood out to us.

First and foremost, many of the newly available tools and technologies are not suited to the needs of the enterprise, particularly in highly regulated industries or major government agencies. Many of the new AI application builders and code generators – and the database platforms supporting them – do not adequately address enterprise requirements for high availability, data sovereignty, global deployment, security and compliance and the need in some cases to run on-premises or in self-managed cloud accounts. As one CIO from a large financial services firm put it to us recently: “We’ve got a couple of dozen AI generated applications end users really want to put into production, but first we’ve got to figure out how to deploy them on our own internal compliant infrastructure.”

Secondly, as compelling as it is to automate workflows with Agentic AI, or to generate new applications with tools like Claude Code, Replit, Cursor or Lovable, the biggest need is to work with existing databases and applications. While some of the newer Postgres-based cloud services work well with Agentic AI and AI app builders for brand new applications they cannot accommodate existing databases and applications without a costly migration – and perhaps to an environment that doesn’t meet the organization’s strict security and compliance requirements. Enterprise customers need AI tooling – including an MCP Server – that can operate against their existing databases.

Additionally we saw there was no dedicated Postgres vendor offering a fully featured and fully supported MCP Server that works with all your existing Postgres databases. Most of the available Postgres MCP Servers are tied to the vendor's own products, and in particular their cloud database offering.

And thirdly, developing new AI applications such as a chatbot running on top of an existing knowledge base, is overly complex with developers having to stitch together too many tools, APIs, Postgres extensions and data pipelines. We saw an opportunity to make it easier to develop AI applications without having to undertake a major exercise in tool sourcing and integration.

We are addressing each of these with the pgEdge Agentic AI Toolkit for Postgres.

Thanks for asking!

Our MCP server does understand how to explore and understand the database schema, and if the knowledgebase package is installed (which you can install from our Enterprise repos, or build one yourself with whatever content you like), it has semantic search capabilities over all the PostgreSQL, pgAdmin, PostGIS, pgEdge and other docs so it has a full understanding of the database and technologies used in it, even if the chosen LLM hasn't been trained on them or only has partial training on them. It can even perform semantic searches over any data you might have embeddings for in the database, provided you configure it to use the correctly embedding LLM, allowing arbitrary semantic searches of content in databases of which it has no prior schema knowledge.

Ours is the only MCP server for Postgres that is fully featured, fully supported by an actual Postgres company AND works with any existing Postgres database on any standard version of Postgres from v14 on.

Note that the MCP server is far better optimised than using psql; it uses lots of tricks to manage token budget, and has tools specifically designed to make database interaction easier, faster, and more efficient.

Now with PostgreSQL 18 support.

It technically is source-available, as of Nov 2024, anyway: https://news.itsfoss.com/cockcroachdb-no-open-source/

So yes, license (and compatibility - see https://pgscorecard.com) are two major differences between pgEdge and CockroachDB.

pgEdge version updates also come in very close alignment with upstream PostgreSQL intentionally to make sure security patches/bugfixes and the latest features get to users ASAP.

You're actually 100% correct! CockroachDB is only 57.25% compatible with standard PostgreSQL (according to https://pgscorecard.com, which details the way it comes up with these numbers) whereas we are 100% compatible (and 100% open-source, whereas they are source-available).

There's a lot of ways to approach the common problems found when running multi-master / active-active PostgreSQL. (A complete guide on this, specifically using PostgreSQL in general, was written by one of our solutions engineers, Shaun Thomas: https://www.pgedge.com/blog/living-on-the-edge)

Could you elaborate on what problems you experienced?

Just a guess, but some of the undocumented edge cases you saw might be explored in this blog from one of our software engineers, Shaun Thomas. It's all about conflict resolution & avoidance in PostgreSQL, in general: https://www.pgedge.com/blog/living-on-the-edge

If understanding how conflicts are handled in pgEdge is helpful, here's a link to the docs on the subject: https://docs.pgedge.com/spock_ext/conflicts

And the FAQ also delves into it some: https://www.pgedge.com/resources/faq

As a note, there's also specific documentation regarding this: https://docs.pgedge.com/spock_ext/conflicts

And, one of our solutions engineers (Paul Rothrock) has a video released a month ago on this topic as well: https://www.youtube.com/watch?v=prkMkG0SOJE

Sharing these alongside my other comment in case additional information is helpful :-)

The official FAQ has a good amount of info on how conflict resolution is handled (https://www.pgedge.com/resources/faq)!

Relevant excerpt: "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."

Some specific documentation on the subject: https://docs.pgedge.com/spock_ext/conflicts

One of our solutions engineers (Paul Rothrock) created a video on this topic in the last month: https://www.youtube.com/watch?v=prkMkG0SOJE

And if you're interested in more information about conflict management in PostgreSQL clusters in general, this article ("Living on the Edge: Conflict Management and You") from Shaun Thomas is probably useful to check out: https://www.pgedge.com/blog/living-on-the-edge

We're not claiming to be a new idea, by any means :-)

Unfortunately, Bucardo is no longer being updated.

Our goal is simply to support continued innovation of distributed PostgreSQL along with similar tools for enabling high availability / scalability in PG deployments.

Getting some examples of real-world cases to share and will comment back with them ASAP; in the meantime, would you mind sharing what undocumented edge cases you came across and what solutions you explored to handle them? It would help with sharing super relevant use cases :-)

Thanks for pointing out the lack of info on conflict resolution in the README! It's been reported and we'll look at getting that updated ASAP.

In the meantime, you can find a lot of information in the official FAQ on how conflict resolution is handled (https://www.pgedge.com/resources/faq), but at-a-glance, "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."

the Getting Started guide is definitely a different mindset than what we would recommend for Production Ready, particularly if there's specific security requirements in mind. With that being said, it should be more clear, so we've reported this to our documentation team to make sure it is!

We're a little different in that we're not just 100% open-source, but also 100% compatible with community PostgreSQL. see https://pgscorecard.com for comparisons between pgEdge and YugabyteDB, CockroachDB on that front.

More thoughts on why we feel that's important here: https://www.pgedge.com/blog/considering-distributed-postgres...

and the Buyer's Guide (https://www.pgedge.com/landing-pages/distributed-postgresql-...) referenced within does list more technical details and comparisons between us and YugabyteDB / CockroachDB.

pgEdge came about from a pglogical foundation, actually! from one of our blogs:

pgEdge emerged in late 2024 as a serverless distributed Postgres managed cloud service, delivering low latency and high availability in three minutes or less. The pgEdge Platform (for on-premises distributed PostgreSQL) as well as pgEdge Cloud (for deploying in the cloud) was largely inspired by the original capabilities of the pgLogical extension.

https://www.pgedge.com/blog/navigating-distributed-postgresq...

agreed!! :-)

Thanks for the feedback! We're pretty excited about it, too :-)

Citus focuses on scaling Postgres via sharding, typically with a single write node and many read replicas. It’s great for high-throughput, analytical workloads. pgEdge, by contrast, is built for geo-distributed, multi-master Postgres — all nodes are writable, with built-in conflict resolution. It prioritizes low latency, availability, and data locality over pure scale-out. So the goals are pretty different.

async multi-master does trade off consistency for availability and latency. In PACELC terms, pgEdge leans into AP/EL, not CP. It’s built for low-latency local writes across regions, with built-in conflict resolution to manage eventual consistency. Definitely not trying to be a NewSQL quorum-write system. Just a different use case.

Thanks for flagging this. You’re right that the issue sat too long without a response, and that’s on us. We’ve now replied on GitHub and are actively looking into it. It appears the crash may be related to CPU feature mismatches (e.g. missing AVX support when using pgvector), especially in emulated environments like ARM Macs running x86 containers. We’ve asked for system details to help confirm. Happy to dig in and resolve it quickly from here.

We definitely really appreciate how open source leads to real innovation and actually useful code; no intention of openwashing here. Thank you for noticing that :-)