AI as Postgres DB, and same real AI DBs

 Turning Claude into Postgres so I can raise a Series A

This article, Turning Claude into Postgres so I can raise a Series A by Jacob Jackson, is a lighthearted technical experiment detailing how he turned Claude (specifically Sonnet 5) into an AI-powered relational database called claudegres.

• The Concept: To capitalize on AI database hype, the author created a experimental database proxy using Buena Vista (a Python Postgres proxy) to convert PostgreSQL wire protocol queries into prompts for Claude.
• Storage & Encoding: Because standard binary database formats don't work well with LLMs, data was persisted to disk using a JSON array format separated by pipe characters (PAGE | ... | ITEM | ...).
• RelCache & Catalogs: To avoid circular references when locating database catalogs on disk, a simplified RelCache was implemented in Python to inject core catalog locations directly into Claude's prompt context.
• Performance & Query Planning:
  • Claude managed basic SQL operations, CREATE TABLE, INSERT, and simple point queries on 5,000 auto-generated rows.
  • Although it created B-Tree indexes, Claude initially cheated by performing sequential table scans until prompted with explicit instructions (and polite encouragement/emojis) to actually traverse the B-tree files.
• Benchmarking & Cost:
  • Tested on Benchbase's Twitter benchmark at a small 0.05 scale, the system processed 4 transactions in 120 seconds (~0.033 TPS), making it about 200,000x slower than a standard PostgreSQL instance.
  • Each transaction cost roughly $0.26 in API tokens, with individual simple queries taking ~10 seconds and $0.03.
• Conclusion: While functional for basic queries, using an LLM directly as a database storage/query engine remains wildly impractical, expensive, and slow. The open-source code is published on GitHub as claudegres.

Turning Claude into Postgres so I can raise a Series A" from ByteofDev, is indeed a brilliant piece of satire[1][2]. It pokes fun at the current tech zeitgeist where investors throw money at anything combining "AI" and "databases," even if the implementation (like using Claude's context window as a literal filesystem) is objectively terrible for performance[1][2].

However, your intuition is completely correct: augmenting databases and APIs with an AI layer is a massive, highly legitimate architectural pattern right now.

The industry has moved rapidly to build middleware, proxies, and "smart layers" that sit in front of traditional data systems. Here is a breakdown of the real-world systems doing exactly what you described:

1. Semantic Caching (The literal "AI Cache Layer")

In traditional systems, a cache (like Redis or Memcached) looks for an exact string match (e.g., SELECT * FROM users WHERE id=5). If it matches, it returns the data. AI systems use Semantic Caching, which caches data based on the intent or meaning of a query rather than the exact text[3][4].

• How it works: If User A asks an AI API, "How do I reset my password?" and User B asks, "What are the steps to recover my account?", a semantic cache converts these queries into vector embeddings and recognizes they mean the same thing[5][6]. It intercepts the API call and instantly returns the cached answer for User B without ever hitting the expensive underlying LLM or database API[5][6].

• Real-world Tools: Redis / Valkey (often used as the backend for this), GPTCache, and API gateways like the Kong AI Semantic Cache plugin all provide this exact capability[4][7][8].

2. AI Gateways and API Proxies

Just as you would put an API Gateway (like NGINX or AWS API Gateway) in front of your backend, developers are now using AI Gateways to sit between their applications and APIs (or LLMs).

• How it works: These tools act as a universal translation and routing layer. They handle semantic caching[5], enforce data schemas (making sure the AI formats the API request correctly), route requests to the fastest/cheapest models, and strip out sensitive PII before a query hits an external API[8].

• Real-world Tools: LiteLLM, Bifrost, Portkey, and Helicone[5][8]. They proxy API access, monitor performance, and provide a buffer between raw LLMs and your production endpoints[5][8].

3. AI-Native Databases (Treating AI Models like Tables)

There are systems that literally merge the concept of a database and an AI model, blurring the lines in a much more practical way than the satirical Claude-Postgres joke.

• MindsDB: This is an open-source federated query engine for AI[9]. It connects to dozens of different standard databases (Postgres, MySQL, Snowflake) and APIs, but allows you to query them alongside AI models using standard SQL[10]. For example, you can write a single SQL query that JOINs a standard Postgres table of customer reviews with an OpenAI model that predicts the sentiment of each review in real-time. The AI is literally treated as a virtual database table.

4. AI Context Engines & Semantic Layers

One of the biggest problems with letting AI access a production database directly is that AI doesn't understand the complex business logic behind raw SQL schemas (e.g., it doesn't know that revenue is calculated by subtracting cancellations from gross_sales).

• How it works: An "AI Context Layer" sits directly on top of the database. When an AI agent needs data, it doesn't write raw SQL. Instead, it queries the semantic layer, which translates the AI's natural language request into safe, pre-approved, highly optimized database queries[11][12].

• Real-world Tools: Wren AI (an open-source context engine for AI agents)[11], Cube (a semantic layer adding AI natural language capabilities)[12], and TiDB (which markets itself as an AI application data layer combining vectors and relational data)[13].

The Irony of the Joke

The ultimate irony of the "Turning Claude into Postgres" joke is that the inverse—turning Postgres into an AI tool—has already happened. The pgvector and pgml (PostgresML) extensions have effectively turned standard PostgreSQL into one of the most widely used AI vector databases in the world, allowing machine learning models to run directly inside the database itself[1][6].

So while the author was joking about using LLMs as a slow, expensive filesystem, the architectural concept of sandwiching AI and databases together to augment access, cache semantics, and orchestrate APIs is currently the hottest area in data engineering.