> 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.
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.
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
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."
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.