{
  "id": 17080610,
  "title": "Built to bend: Postgres’s inventor and a steward on what AI really needs",
  "url": "https://urgent.news/2026/10/29/built-to-bend-postgress-inventor-and-a-steward-on-what-ai-really-needs",
  "topic": "ai",
  "section": "AI",
  "published": "2026-10-29T15:00:00.000Z",
  "source": {
    "name": "The Register Science",
    "slug": "the-register-science",
    "url": "https://www.theregister.com/databases/2026/10/29/partner-content-built-to-bend-postgress-inventor-and-a-steward-on-what-ai-really-needs/5305957"
  },
  "original_language": "en",
  "account": "Michael Stonebraker, a Turing Award winner and MIT professor, introduced Postgres® in 1986. Today, it remains a leading choice for AI projects and its designer is among the most cautious about how they are being built. Bruce Momjian, a cofounder of the PostgreSQL Global Development Group and a core team member at EnterpriseDB, works alongside Stonebraker. Both are featured in upcoming episodes of AI & Data Horizons by EnterpriseDB to argue for bendable systems over controlled ones.\n\nStonebraker's first point is text-to-SQL, allowing business users to ask questions in plain English and get answers from the warehouse. Public benchmarks report accuracy above 80 percent. However, when tested on MIT's data warehouse of 1,400 tables using real queries, his team achieved zero-percent accuracy. Adding agentic AI, retrieval, and prompt engineering improved this to the teens. Even with the model informed about every table and join term, they only reached the 30s. Stonebraker insists this is not ready for prime time.\n\nThe main issue, he claims, lies in the architecture. While language models excel at text, they struggle with structured data joins, which form most of an enterprise's data. Working with Munich's transport department, Stonebraker's team discovered that handling a single citizen's complaint about crosswalk timing required integrating regulations, CAD drawings, trolley schedules, and school-zone maps. Using a language model at the core proved to be prohibitively expensive. Their solution, Rubicon, uses models only for text analysis, converting results into tables, and then handling the rest with a tabular engine. This architecture, resembling a query optimizer, is reportedly 10 times cheaper and more accurate than model-based frameworks.\n\nStonebraker expects agentic AI to fall from the hype cycle into a valley of despair. Enterprises dislike non-determinism; if they approve a loan and it gets reversed on review, it could lead to lawsuits. Additionally, organizations need protection from rogue agents. The guardrails inside the database already exist, comprising decades of access control, complete logs, and triggers that can halt transactions. Data-heavy agents should reside inside the data layer as user-defined functions, once their debugging and versioning tools improve.\n\nStonebraker also criticizes the hype around artificial general intelligence (AGI) from foundation model vendors. No enterprise would allow a model to train on its proprietary data. As for AGI, he considers it \"basically marketing hype.\"\n\nPostgres is both the chosen database and a testament to Stonebraker's philosophy. It is open-source, not controlled by any single company, and its strength lies in its flexibility and adaptability. Its features, such as JSON, full-text search, GIS, and AI, have been added without a complete overhaul. Momjian echoes this sentiment, emphasizing Postgres's community-driven nature, its early foresight, and its ability to produce software superior to those developed by billion-dollar companies.\n\nBoth experts advocate for a design philosophy that prioritizes flexibility over marginal speed improvements. Postgres was built to be extensible, allowing it to incorporate various functionalities seamlessly. Similarly, leaning on the operating system rather than absorbing it has made Postgres an ideal fit for cloud environments. The project plans to prioritize reliability over speed, with upcoming features like SQL property graph queries, partition merging, and splitting being postponed due to reliability concerns. Practical enhancements like REPACK CONCURRENTLY, smarter parallel autovacuum, and sequence synchronization for logical replication are on the horizon.",
  "summary": "PARTNER CONTENT: Michael Stonebraker and Bruce Momjian on why enterprise AI needs a database that no one controls, and what PostgreSQL 19 says about the road ahead",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}