One engine

One database for everything your AI agent remembers.

Pick a story to walk through. Both make the same point: one TiDB cluster does the work of four separate databases, so nothing is ever out of sync.

Agent memory

Your coding agent forgets everything between sessions.

Open a new session and it has no idea what you decided last week. To catch up it re-reads the whole past conversation, and every re-read word costs money (tokens are what you pay the AI model for). Worse: when its head gets too full, it quietly drops the oldest decisions. Storing its memory in one TiDB table fixes both. Click Start to load a real coding-agent history.

One table. Every turn is one row.

Act 1 · without memory

Chat with it. Watch its head fill up.

This agent has a deliberately small head: about 6,000 tokens of context. It also keeps a small notes file, where it writes down whatever it judges important. You chat on the left; the right shows the inside of its head and that notes file. Pick your first message.

Inside its head · context window
Context window
0%
Outside its head · its notes file

Act 2 · with TiDB memory

Same chat. This time every turn is also saved.

One change: as you chat, each message is also stored as a row in a real TiDB table and auto-embedded, turned into a searchable meaning-vector, on insert. The head still fills and still compacts. Watch what happens to the same final question.

Inside its head · context window
Context window
0%
Outside its head · TiDB agent_memory table
See the real table, its rows, and the query
Loading live rows…

One engine

One database instead of four. A fraction of the tokens.

Databases are moving from system of record to system of thought.

One engine

Everything your AI agent remembers, from one database.

You run an online shoe store, and all of its data lives in one TiDB cluster. The next four steps each show one job your app does behind the scenes with that data. The shopper never sees these directly. Then a real customer question puts all four together, answered the old way (four databases) versus TiDB.

One cluster. Four jobs. No copies.

Behind the scenes · OLTP

1. Look up one exact thing.

The everyday database job: pull up a specific customer's order and account, exactly and instantly. Example below: find Maya's open orders.

View or edit the SQL

Behind the scenes · OLAP

2. Crunch a lot of history.

The analytics job: roll up months of orders into one answer, like "what do people who return this shoe switch to?" Normally a separate warehouse; here it is the same cluster, same data, no copy.

View or edit the SQL

Behind the scenes · Vector search

3. Search by meaning.

Type what you mean, not the exact words. "Shoes that won't rub on long runs" finds the right products even with no matching keywords, because TiDB turns text into vectors and matches by meaning. Normally a separate vector database; here, same cluster.

Behind the scenes · Full-text

4. Search by keyword.

Exact keywords, ranked by relevance, like a search engine, built in. Normally a separate search engine; here, same cluster. Meaning + keyword together is called hybrid search, and it is what the agent uses in the next step.

Customer-facing · AI agent

Now a real support question.

This is the part the shopper sees. Maya messages support, and to reply well the AI agent needs everything from the last four behind-the-scenes steps at once: her order, the return trend, her preferences, and the catalog. Pick her message and watch it answer two ways, the old way (four separate databases) and TiDB (one). Start on the old way.

Pick the message Maya sends to support:
Or ask your own
What's inside each engine

Playground

Try it with your data.

Paste rows or load a preset, then ask anything. All four retrieval styles, one engine. Inserts are searchable instantly, no ETL.

1 · Load data

2 · Ask your own questions