DynoTable
Beginner6 min read

How to Query DynamoDB with AI (Natural Language)

"Show me last week's failed orders" is a one-liner in your head and a KeyConditionExpression with placeholder maps on the wire. Closing that gap is what "query DynamoDB with AI" actually means — because the DynamoDB API itself has no natural-language endpoint. Every request is still expressions or ; AI sits in the tooling layer, translating your intent into them.

That translation can be genuinely great or quietly dangerous, depending on one thing: whether the model can see your real schema. This guide covers the three working setups and where each one breaks.

How do I query DynamoDB using natural language?

Three real options: ask a general LLM to draft PartiQL and run it yourself (fast, but the model is guessing your attribute names), connect an AI agent to DynamoDB through an MCP server so it can inspect and query for real, or use a DynamoDB client with a built-in schema-aware assistant — DynoTable's AI chat turns plain language into PartiQL or SQL against your actual indexed schema, computes exact whole-table aggregates, and stages any write for your review.

Option 1: LLM-drafted PartiQL, run by you

The zero-setup version: describe the query to any capable model, get PartiQL back, run it in the console's PartiQL editor or via the CLI:

aws dynamodb execute-statement \
  --statement "SELECT * FROM \"Orders\" WHERE PK = 'ORDER#1001'"

It works — and it fails in three predictable ways:

  • The model can't see your table. It will confidently invent attribute names and key shapes (orderId when yours is PK = ORDER#<id>). You end up debugging hallucinated schema instead of writing the query.
  • PartiQL's limits still apply. A SELECT reads exactly one table, and a WHERE that doesn't pin a key becomes a full table scan — silently expensive, exactly as if you'd written it yourself. The model rarely warns you; PartiQL vs SQL explains what the SQL surface does and doesn't buy.
  • Pasting schema or data into a chatbot is a data-governance decision. Sample items in a prompt are production data leaving your boundary.

Good for one-off queries on a schema you can paste from memory; shaky as a workflow.

Option 2: an AI agent connected via MCP

The structural fix for "the model can't see your table" is to give the agent tools instead of a prompt-pasted schema. The Model Context Protocol (MCP) does exactly that: an MCP server exposes DynamoDB operations as typed tools, and any MCP-capable agent (Claude, IDE assistants, custom agents) can list tables, inspect keys, and run queries with real results feeding back into the conversation.

We cover the full setup — and the consent, scoping, and write-safety questions that come with letting an agent touch a database — in Using DynamoDB with an MCP server. DynoTable itself ships one: it can expose gated, loopback-only tools to external agents, with per-connection consent and scopes.

This is the right architecture when the agent is the product — a support bot, an internal Slack assistant. For interactive day-to-day work, it still leaves you assembling agent, server, and credentials yourself.

Option 3: a schema-aware assistant in your DynamoDB client

DynoTable's built-in assistant is the integrated version: it lives next to your tables (⌘;), and it reads your indexed schema — the tables under the active profile, their keys and indexes, the attribute paths and types discovered by table indexing, even sample values — so "filter this to last week" resolves against your real attribute names, not a guess. Type @ to reference a @table, @column, or @gsi explicitly.

The DynoTable AI chat docked beside a table tab: a plain-language question, the generated query, and the result opening as a view.
The DynoTable AI chat docked beside a table tab: a plain-language question, the generated query, and the result opening as a view.

What it does with a question, per the capability catalog:

  • Writes the query for you — read-only PartiQL, or Workbench SQL when the question needs JOIN / GROUP BY / aggregates (the analytics DynamoDB's API doesn't have) — and proposes the result as a chip you click to open as a real tab.
  • Computes exact whole-table answers. Ask for a count, sum, average, or per-group breakdown and it reads every matching item, not a sampled page — "how many orders last month?" reflects the actual table. It can reshape the same pass into a transformed export file.
  • Stages every write. Ask it to fix a row and the change lands in the staging area as a reviewable diff — the assistant cannot write to DynamoDB directly, batch-delete a table, or alter table structure, in any permission mode. You review, you commit.
  • Asks before spending your money. Reads that hit AWS and cost capacity are permission-gated (Manual / Auto / Full Auto, per profile), and every gated decision lands in a local, always-on audit log.

The trust model matters as much as the features: the assistant runs on your own AWS Bedrock credentials, talking directly to Bedrock in your account — prompts, schema, and table data never route through DynoTable's servers, and inference is billed to you at Bedrock's own rates with no markup. Tool results are treated as untrusted data, so a row containing "ignore previous instructions" can't hijack the agent.

What AI does NOT change about DynamoDB

Any honest AI layer inherits the database's physics:

  • Access patterns still rule. "Where status = X" over a non-key attribute is a filtered scan no matter who writes it — the model just types the expensive query faster. If a question keeps forcing scans, the fix is modeling (a GSI, a better sort key), not a better prompt.
  • Reads cost real capacity. An exact whole-table aggregate is a whole-table read. Good tools gate it and say so; the pricing calculator tells you what a full pass costs before you approve it.
  • Determinism has its place. For a query you'll run forever in production, hand-build the expression once in the Expression Builder and ship the exact names/values maps — AI is for exploration, the builder is for the code you commit.

FAQ

Can I query DynamoDB in plain English? Not against the API itself — DynamoDB only speaks expressions and PartiQL. But an AI layer can translate: an LLM drafting PartiQL, an MCP-connected agent, or a schema-aware assistant like DynoTable's that generates and runs the query against your real schema.

Does DynamoDB have a built-in AI query feature? The DynamoDB API has no natural-language endpoint. Whatever AI querying you get comes from the tooling layer on top — which is why the safety model of that tooling (read gates, staged writes, your own credentials) is the thing to evaluate.

Is it safe to let AI near production data? It's a permissions question. Look for: reads gated behind explicit approval, writes that land in a reviewable staging area instead of executing directly, an audit log, and inference on credentials you control. DynoTable's assistant meets all four; a chatbot with your pasted data meets none.

Can the AI join tables or do GROUP BY? Not via the DynamoDB API — no engine exists for it. DynoTable's assistant answers those questions through its read-only Workbench SQL (real JOIN, GROUP BY, and aggregates within DynamoDB's access-pattern rules), which is also where count/sum/average questions land.

What does it cost? Two meters: DynamoDB read capacity for whatever the queries touch (the assistant asks before gated reads), and Bedrock inference billed to your own AWS account — DynoTable adds no markup and proxies nothing.

Ask your next question in plain language — download DynoTable, point AI at your own Bedrock, and keep every write behind a review.

Updated