EDB Builds a Semantic Layer for Agents into Postgres and Connects It to Bedrock

The classic text-to-SQL problem: the agent sees column names but does not understand the business behind them. It does not know that a "big customer" at your company means an order above 250 dollars, or that the price column stores the total of the whole order. The result is neat but wrong numbers. In another article in its series on semantic layers, AWS shows EDB's approach: instead of setting up a separate system of meanings, put it in the same Postgres where the data lives.

How it works

EDB Postgres AI includes the AIDB extension. It creates a semantic knowledge base (SemKB) on top of the schema. It ingests definitions of tables, views and columns along with the text from COMMENT ON. All of this is turned into embeddings, and the agent finds the right table by meaning rather than by name. Foreign keys are automatically turned into join paths between tables.

Authoring comes down to three things. First: column comments. Second: business terms as views with their own comment, for example a big_spender view, where the definition lives in one place for all agents and dashboards. Third: semantic aliases, that is, named parameterized SELECT statements with a natural-language description. The agent finds such an alias by meaning and calls it as a ready-made tool.

The article's example makes the cost of a mistake clear. If the agent reads purchases.price as a unit price and multiplies it by quantity, the top customer comes out at 502,529 dollars instead of the real 27,991.66. A single column comment closes this hole.

How the agent reaches the data

The flow is as follows. An analyst logs in through Amazon Cognito and calls AgentCore Gateway with a JWT. The Gateway checks the token and the Cedar policy, then routes the request to the agent runtime on Strands Agents, where Claude on Bedrock does the planning. The agent calls tools via MCP. The edb-endpoints server built into AIDB already speaks streamable HTTP MCP with Basic authentication, so the Gateway connects to it directly through an Application Load Balancer. No Lambdas or intermediate layers are needed.

The Postgres role's password is stored by AgentCore Identity, which inserts it into every outgoing request. The agent code never sees this password.

Postgres decides permissions, not the prompt

The most useful part of the article is governance. The MCP endpoint has no permission system of its own: what is allowed is decided by ordinary GRANTs. Each request opens a separate connection under the login from the Basic header, so current_user inside the tool is the agent's role, and it is visible in pg_stat_activity.

The authors create two roles. mcp_agent_full sees everything, mcp_agent_restricted sees everything except customers.ssn. The prompt, the tool catalog and the agent code are identical. When asked to "show five customers with their social security numbers," the first role gets the data, the second gets a permission denied error, which MCP passes through unchanged. Row-level security can also be enabled so that different roles see different rows.

Auditing also stays in the database. AIDB writes OpenTelemetry traces of SQL execution to the aidb_otel schema, and they can be analyzed with ordinary SQL. AgentCore traces for tool calls, LLM and tokens go to CloudWatch.

What to do with this

If you have an operational Postgres and are building an agent for analytics or support, start with the cheap steps: write a COMMENT for non-obvious columns and move business terms into views. This improves accuracy even without AIDB.

There are limitations too. This is a solution built around the EDB ecosystem: AIDB, its AMI and the MCP server. SemKB indexes the schema, not the data, so quality depends on discipline in comments. Models on AWS are not available in all regions. The example is built on a small demo set of four tables, and on hundreds of tables semantic search will need separate verification.

Bottom line: the idea that "meaning and permissions live next to the data" removes a whole class of catalog synchronization problems and lets you trust access restrictions more than requests in a system prompt.