> 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?
To clarify, I was working with 2nd Quadrant BDR (now Enterprise DB Postgres Distributed), running on some extremely large EC2 instances, in a global mesh - IIRC, five regions. Also in fairness, EDB told us that we were the largest mesh they had seen, and so we frequently ran into fun edge cases.
Each node had N replicas running vanilla Postgres attached, which were on EC2s with node-local NVMe drives for higher performance. This was absolutely necessary for the application. There were also a smattering of Aurora Postgres instances attached, which the data folk used for analytics.
In no particular order:
* DDL is a nightmare. BDR by default will replicate DDL statements across the mesh, but the locking characteristics combined with the latency between `ap-southeast-2` and `us-east-1` (for example) meant that we couldn't use it; thus, we had to execute it separately on each node. Also, since the attached Aurora instances were blissfully unaware of anything but themselves, for any table-level operations (e.g. adding a column), we had to execute it on those first, lest we start building up WAL at an uncomfortable pace due to replication errors.
* You know how it's common to run without FK constraints, because "scalability," etc.? Imagine the fun of having devs manage referential integrity combined with eventual consistency across a global mesh.
* Things like maximum network throughput start to become concerns. Tbf, this is more due to modern development's tendency to use JSON everywhere, and to have heavily denormalized tables, but it's magnified by the need to have those changes replicated globally.
* Hiring is _hard_. I can already hear people saying, "well, you were running on bare EC2s," and sure, that requires Linux administration knowledge as a baseline - I promise you, that's a benefit. To effectively manage a multi-master RDBMS cluster, you need to know how to expertly administrate and troubleshoot the RDBMS itself, and to fully understand the implications and effects of some of those settings, you need to have a good handle on Linux. You're also almost certainly going to be doing some kernel parameter tuning. Plus, in the modern tech world, infra is declared in IaC, so you need to understand Terraform, etc. You're probably going to be writing various scripts, so you need to know shell and Python.
There were probably more, but those are the main ones that come to mind.
I don't recall which customer you may have been, but the standard solution to that specific DDL issue with BDR is to use Stream Triggers to enable row versioning. One of the 2ndQuadrant customers used it extensively for multi-region cross-version app schema migrations that could last for months.
Essentially what that boils down to is you create stream triggers that intercept the logical stream and modify it to fit the column orientation by version. So during the transition, the triggers would be deployed to specific nodes while modifications are rolled out. Once everything was on the new version, triggers were all dropped until the next migration.
Spock doesn't have anything like that _yet_, but as you observed, being unable to use DDL replication significantly increases complexity, and tmux is a poor substitute.
Version 3.6 is definitely after we introduced that functionality. It was, alas, rarely deployed though. Usually clients needed a consultant to put together a configuration for them, and most didn't bother.
Can I ask more about this? I assume you created a procedure around making DDL changes to the global cluster... what was that procedure like? what tools did you use (create) to automate/script this? what failure modes did it encounter?
Bold of you to assume it was automated. The process I used was tmux with pane synchronization.
I asked to automate it (probably would've just been a shell script, _maybe_ Python, issuing SQL commands to stdin), but people were afraid of unknown unknowns.
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
> 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....