This blog is about my work on the Postgres open source database, and is published on Planet PostgreSQL. PgLife allows monitoring of all Postgres community activity.
Online status:
Unread Postgres emails:
Email graphs:
incoming,
outgoing,
unread,
commits
(details)
Comment to the Mcp Rescue
Monday, March 16, 2026
The comment command has been in Postgres for decades. It allows text descriptions to be attached to almost any database object. During its long history, it was mostly seen as a nice-to-have addition to database schemas, allowing administrators and developers to more easily understand the schema. Tools like pgAdmin allow you to assign and view comments on database objects.
Now, in the AI era, there is something else that needs to understand database schemas — mcp clients. Without database object comments, mcp clients can only use the database schemas, object names, and constraints. With database comments, database users can supply valuable information to allow mcp clients to more effectively match schema objects to user requests and potentially generate better sql queries. If database users don't want to add such comments, it might be possible for generative AI to create appropriate comments, perhaps by analyzing data in the tables.
RSS
Wednesday, March 11, 2026
For much of Postgres's history, it has lived in the shadow of other relational systems, and for a time even in the shadow of NoSQL systems. Those shadows have faded, but it is helpful to reflect on this outcome.
On the proprietary side, most database products are now in maintenance mode. The only database to be consistently compared to Postgres was Oracle. Long-term, Oracle was never going to be able to compete against an open source development team, just like Sun's Solaris wasn't able to compete against open source Linux. Few people would choose Oracle's database today, so it is effectively in legacy mode. The Oracle shadow is clearly fading. In fact, almost all enterprise infrastructure software is open source today.
The MySQL shadow is more complex. MySQL is not proprietary, since it is distributed as open source, so it had the potential to ride the open source wave into the enterprise, and it clearly did from the mid-1990s to the mid-2000s. However, something changed, and MySQL has been in steady decline for decades. Looking back, people want to ascribe a reason for the decline:
People have been scrambling to figure out the future of MySQL. Users are pleading for Oracle to improve, and Oracle has promised improvement. Even without Oracle, MariaDB has struggled.
So, what is the root cause of the MySQL ecosystem decline? Some even blame Postgres, but I think the cause goes back to the beginning of MySQL, and frankly to MySQL AB. From the beginning, MySQL was distributed as open source, but developed as closed source, i.e., development was controlled by a single company. Externally-submitted patches were rewritten so MySQL AB could monetize non-gpl versions of the software, and big customers drove the product roadmap. For their first ten years, MySQL AB was able to eclipse Postgres, because they could send speakers to many conferences and give enterprises a simple on-ramp to an open-source-distributed database. However, this system couldn't last because the fundamental impediments of company-controlled development would eventually slow it down. I remember I used to explain this to MySQL users at the time, and I am sure many thought I was biased because I worked on Postgres. Who controlled development seemed inconsequential to them, and MySQL's fame was soaring, so my concerns were easily dismissed.
Fast forward a decade, and the cracks started to appear. Company-controlled development just can't complete with open source communities. Short term, company spending can hide the problem, but most companies can't sustain the spending, which is probably why MySQL AB was eventually sold to Sun. Even Oracle can't compete long term against open-source-developed Postgres, and their support of Postgres in their cloud proves that. Oracle's treatment of customers reinforces the argument that Oracle doesn't expect long-term customer relationships.
In summary, MySQL was destined to end this way from the start — first controlled and monetized by MySQL AB, then controlled by Sun and Oracle. Others forked the code, either to create new offshoots, e.g., MariaDB, or to customize in-house versions, e.g., Meta. Everyone wanted to control it, so hence no one did. There was no strong development community behind MySQL to counter the advantages of software control.
For Postgres, many companies have tried to control it, either via fork and run (do not merge in new features from the community), or fork and follow, i.e., become a better Postgres that hopefully becomes everyone's default. Companies large and small have tried, and failed. The community is just too large, too strong, and too dynamic. You can fork for a while, but eventually the gap between what the company develops, and what the community develops, grows too large, and you have to "follow" by merging in the community changes. If the fork is highly modified, merging can be time-consuming, which discourages changes that diverge too much from the community distribution. These forces keep companies attached to the Postgres ecosystem, working on the community code, and keeping their enhancements to Postgres to a minimum.
I was talking to a MySQL vendor last week at scale, and as part of their pivot to add Postgres support, we started talking about MySQL. She felt MySQL had one more chance to regain momentum. I said I was skeptical, and explained many of the issues above. Her shoulders sank as I spoke, and I think reality started to set in — a MySQL revival is unlikely. Years ago, before the ascendency of Postgres, there might have been a chance if MySQL development had been opened. However, that time has passed, and the rebound options have faded.
Post a CommentSaturday, March 7, 2026
I just gave a new presentation at scale titled The Wonderful World of Wal. I am excited to have this second new talk this year. (I have one more queued up.)
I have always wanted to do a presentation about the write-ahead log (wal) but I was worried there was not enough content for a full talk. As more features were added to Postgres that relied on the wal, the talk became more feasible, and at 103 slides, maybe I waited too long.
I had a full hour to give the talk at scale, and that was helpful. I was able to answer many questions during the talk, and that was important — many of the later features rely on earlier ones, e.g., point-in-time recovery (pitr) relies heavily on crash recovery, and if you don't understand how crash recovery works, you can't understand pitr. By taking questions at the end of each section, I could be sure everyone understood. The questions showed that the audience of 46 understood the concepts because they were asking about the same issues we dealt with in designing the features:
I was happy with the outcome and look forward to giving the talk again soon.
Post a CommentWednesday, January 28, 2026
I just gave a new presentation at Prague PostgreSQL Developer Day titled What's Missing in Postgres? It's an unusual talk because it explains the missing features of Postgres, and why. One thing I learned in writing the talk is that the majority of our missing features are performance-related, rather than functionality-related. I took many questions:
Thanks to Melanie Plageman for the idea of this talk.
Post a Comment