Testing DBX's AI SQL Assistant on a Small SQLite Dataset

Can an AI SQL assistant preserve a filtering rule when you add a condition in a follow-up? I tried a small case in DBX: total each customer's completed orders, then keep only customers whose total is strictly greater than 30,000 cents.

Both generated queries returned the expected results without manual SQL edits. That is a useful observation, but it covers just two prompts against a database with three fictional customers and six orders. Here is the setup, the SQL, and the parts of the interface that needed attention.

What was tested

The download came from the DBX website, using the v0.6.67 release. The release tag and executable version use different labels, so I have included both.

The model settings were configured before the AI test. “MiniMax-M3” is the name displayed in the selector; the test did not inspect or change credentials, independently verify the backend model or endpoint, check billing, or measure generation time.

Windows was controlled through the UFO single-step API: inspect a screenshot, choose an action, then inspect the next screenshot. The caller checked the SQL and clicked Execute. This was not a test of DBX's Agent mode completing the task autonomously. AI also assisted with writing and translating this article.

The application, prompts, and sample names were in Chinese. The screenshots below are the original test captures; English captions explain what to look for. Prompt translations are for readers, not evidence of an additional English-language test.

Start with a local SQLite file

The database file was named sample.sqlite, and the connection was named DBX-Review-20261106. The connection steps were:

1. Click New Connection (新建连接).
2. Choose SQLite under Lightweight Databases (轻量数据库).
3. Enter the connection name and select the sample file.
4. Click Test (测试), confirm the successful connection message, then Save and Connect (保存并连接).
5. Expand main → 表 (Tables) to find customers and orders.

No separate SQLite server was needed, and this setup did not require an extra driver-installation step. After connecting, opening orders displayed all six rows.

Two rows make this more useful than a query that merely runs: customer 1 has a cancelled order for 99,000 cents, and customer 2 has a pending order for 60,000 cents. Neither belongs in the completed-order totals.

Here, “cents” means integer hundredths of the sample currency, yuan. Keeping the stored values as integers also makes the result easy to check without rounding.

Establish the expected result first

In a new query tab, this handwritten query groups completed orders by customer:

SELECT c.name, SUM(o.amount_cents) AS total_cents FROM customers AS c JOIN orders AS o ON o.customer_id = c.id WHERE o.status = 'completed' GROUP BY c.id, c.name ORDER BY total_cents DESC, c.name; 

DBX's formatting button laid out the single-line input as readable SQL. Executing it displayed these results below the editor:

The English names and yuan conversions are additions for this article. DBX returned the original Chinese names and integer totals.

The arithmetic is small enough to check against the source rows: 30,000 + 18,000 = 48,000 for Xinghe Studio, 30,000 for Qingshan Design, and 12,000 for Yuanfan Consulting. The pending and cancelled orders are excluded, and the results are sorted by total descending.

The status bar showed three rows and 4 ms. That was one UI readout on a tiny dataset, not a performance benchmark. Startup time and the time to complete the full workflow were not measured either.

Ask the model for the same query

The model was not configured on the first day. Once configuration was complete on the second day, the assistant panel opened from the robot icon offered MiniMax-M3. A fresh conversation used the sample connection, the main database, and general Q&A mode.

The first prompt supplied the schema and business rules, but not the expected result rows. Translated from Chinese:

Generate a read-only SELECT query for the current SQLite sample database. Do not execute it or modify data. The tables are customers(id, name) and orders(id, customer_id, amount_cents, status), with orders.customer_id referencing customers.id. Sum orders whose status is completed for each customer. Return only the customer name as name and the sum as total_cents, keeping amounts in integer cents. Sort by total descending, then customer name ascending. Exclude pending and cancelled orders. Provide executable SQL and briefly explain the filtering, join, and amount unit.

The main query in the first response was:

SELECT c.name AS name, SUM(o.amount_cents) AS total_cents FROM orders AS o JOIN customers AS c ON c.id = o.customer_id WHERE o.status = 'completed' GROUP BY c.id, c.name ORDER BY total_cents DESC, c.name ASC; 

Its join, status filter, integer amount unit, and ordering match the handwritten query. The response also explained that pending and cancelled orders are filtered before aggregation, and that grouping by customer ID avoids merging customers who share a name.

After checking that it was a read-only SELECT, the caller clicked Execute Now (立即执行) on the code card. DBX reported three rows. The corresponding query tab showed the same totals: 48,000, 30,000, and 12,000 cents. The first statement was run again in that tab to capture the result shown below; it was not regenerated or manually edited.

Follow up with a boundary condition

The next prompt reused the conversation without repeating the schema. Again, this is an English translation of the submitted Chinese prompt:

Keep the previous rule of counting only completed orders. Retain only customers whose total_cents is strictly greater than 30000 cents. Still return name and total_cents, with the same ordering. Generate read-only SQL only; do not execute it or modify data. Briefly explain whether this filter belongs before or after aggregation.

The response retained the original WHERE condition and added this after GROUP BY:

HAVING SUM(o.amount_cents) > 30000 

The distinction matters: WHERE filters individual orders; HAVING filters customer totals after aggregation. The response explained that a total equal to 30,000 would not qualify.

After checking and executing the statement, the result contained just Xinghe Studio at 48,000 cents. Qingshan Design, with exactly 30,000, was excluded.

There was one generation per prompt and zero manual SQL edits in either round. That describes these two cases; it does not establish a general accuracy rate.

What helped, and what needed attention

Keeping the prompt, explanation, SQL, and execution in one application saved the step of copying a query from an external chatbot into a database client. The follow-up also kept the original completed-order rule while adding the total threshold.

A few details required care:

• The response offered more than one interpretation. Alongside the main query, it supplied an alternative that would retain all customers and show zero when they had no completed orders. Only the main query was executed. The alternative was not tested, so choosing the correct code card still mattered.
• Execution opened another query tab. In this test, applying or executing the generated SQL created a separate tab. The previously visible tab kept its old result. The “open tabs” menu was needed to find the new result and confirm which statement had run.
• Some extra English marker text appeared in the responses. The SQL and explanations remained usable, but the markers interrupted reading. Their origin was not diagnosed; the evidence does not establish whether they came from the model's output format or client rendering.
• Model configuration is a separate step. These results came from a configured setup, not an untouched download. They say nothing about service cost or generation speed.

For the basic SQLite workflow, the layout was convenient: database tables on the left, SQL in the editor, and results below. Some toolbar actions were icon-only, though, and finding the formatting button took a little effort at first.

There was also a problem in the automation input path: entering multiline SQL quickly lost line breaks. Entering a single line, formatting it in DBX, and then executing it worked. The cause remains unresolved; this does not establish that ordinary manual typing has the same issue. The successful results in this article were checked in DBX after that input adjustment.

This test did not cover writes, complex business schemas, automatic discovery of an unknown schema, other models, MySQL, PostgreSQL, remote connections, large datasets, exports, or comparisons with other clients. Initial configuration effort also needs further evaluation.

For opening a local SQLite file and checking a small aggregation, the workflow worked. With an explicitly supplied schema, the two AI queries also produced the expected results. I would want broader tests before relying on it for unfamiliar business data.

Reproduce the sample

Run this initialization script in a new, empty SQLite test database, then execute the queries above. All customer names and orders are fictional. The Chinese names are retained so the results match the screenshots.

BEGIN; CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT NOT NULL); CREATE TABLE orders ( id INTEGER PRIMARY KEY, customer_id INTEGER NOT NULL REFERENCES customers(id), amount_cents INTEGER NOT NULL, status TEXT NOT NULL CHECK (status IN ('completed', 'pending', 'cancelled')) ); INSERT INTO customers VALUES (1, '星河工作室'), (2, '青山设计'), (3, '远帆咨询'); INSERT INTO orders VALUES (1, 1, 30000, 'completed'), (2, 1, 18000, 'completed'), (3, 1, 99000, 'cancelled'), (4, 2, 30000, 'completed'), (5, 2, 60000, 'pending'), (6, 3, 12000, 'completed'); COMMIT; 

Original Chinese prompts used in the test

First prompt:

请针对当前 SQLite 样例库生成一条只读 SELECT 查询，不要执行或修改数据。表结构是 customers(id, name) 和 orders(id, customer_id, amount_cents, status)，orders.customer_id 关联 customers.id。请按客户汇总 status 为 completed 的订单金额，只返回客户名称 name 和合计 total_cents，金额保持整数分，按合计降序、客户名称升序排列；pending 和 cancelled 订单不要计入。请给出可执行 SQL，并简短解释过滤、关联和金额单位。

Follow-up prompt:

沿用刚才只统计 completed 订单的口径，只保留合计 total_cents 严格大于 30000 分的客户，仍返回 name、total_cents，排序保持不变。只生成只读 SQL，不执行，不修改数据；简短说明应该在聚合前还是聚合后筛选。

How do you check an AI-generated aggregation query before trusting its result? I would be interested in examples of filters, joins, or boundary conditions that your usual workflow catches—or misses.

This article is an English adaptation of my Chinese test report on Juejin. I also maintain a directory of office and open-source tools, with source-based introductions distinguished from hands-on tests. Feedback is welcome in the comments.

Screenshots show the actual DBX test windows. Only the outer black borders were cropped and local file paths obscured; SQL, data, and results were not edited.