Selection and trial

The short answer: AskTable fits teams with a clear business problem, data they can open to the product, and someone accountable for metric definitions. It is not a general-purpose chatbot, an RPA tool, or a replacement for a traditional BI platform.

The numbers below support selection meetings and POC planning. They are not unconditional commitments for every customer or every question. Current pricing and promotions are governed by the official pricing page and the signed contract.

Quick fit check

Boundary with BI

Three lines:

1. Keep BI for fixed reports, dashboards, subscriptions, and controlled publishing.
2. Use AskTable for ad-hoc questions, follow-ups, changing definitions, and explanations.
3. BI's metric layer and datasets feed AskTable. AskTable does not build a warehouse, run ETL, or write back to BI.

Pricing and plan boundaries

Cloud (SaaS)

• Administrators, members, and guests all count toward the user limit.
• During the promotion, paid organizations have unlimited AI Q&A within reasonable-use boundaries. When the promotion ends or changes, the official page and the contract govern.
• If the organization page shows credits, periodic credits are consumed first and add-on credits second. Periodic credits do not roll over; the organization page and contract define the actual amounts.
• Cloud is licensed by organization plan; private deployment is licensed by enterprise license. Actual features and capacity follow the applicable license.

Pricing checked on 2026-10-22. See the official pricing page for the current version.

Private deployment

• Sales quotes private deployment based on the deployment environment, data scale, delivery scope, and service period. There is no single public price.
• Without an activated enterprise license, the instance runs as a trial: at most 3 users, and Analysis Canvas is disabled.
• An enterprise license is issued by user capacity. The license defines the available features, capacity, and validity period.
• Minimum deployment: 4 CPU cores, 16 GB RAM, and 100 GB disk. See the next section for the recommended configuration.

How to start a trial

• Cloud: register at cloud.asktable.com and use the free trial quota to connect your own data and ask questions. Upgrade to a paid plan when you need to invite colleagues, collaborate as an organization, and manage permissions.
• Private deployment: start with the trial edition, which supports at most 3 users and does not enable Analysis Canvas. Buy an enterprise license by user capacity after the POC.
• Do not evaluate with demo data alone. Choose 3–10 real core tables and record the pass rate with the 100-question method below before deciding whether the product fits.

Concurrency benchmark: how many people can 8C32G support?

Separate three numbers first:

Recommended configuration and result

8C32G is the recommended machine specification. The product defaults to one Worker with 10 tasks each. To cover 20 simultaneous users, raise the Worker count to two, for 20 concurrent analysis tasks.

With the default single Worker, there are only 10 concurrent analysis tasks; plan for up to 10 users. For 20 users, raise AT_WORKER_NUM_PROCS to 2 first.

Validated environment and planning limit

The 20-user figure for 8C32G is capacity planning based on task count, not a same-scale load-test result. The environment actually validated with 20 simultaneous users is 16C64G: the application layer accepted 10 questions per second, and 20 business users started natural-language questions at the same time. The queue smoothed the load, and the result passed. This 10 QPS is acceptance capacity, not 10 completed answers per second.

One group customer hit a model-concurrency bottleneck in its procurement platform: the initial model API key allowed only 5 concurrent requests, which was insufficient at peak. After raising model concurrency above 20, the backend was configured with 16 cores, 4 Workers, and 10 tasks per Worker, for 40 concurrent tasks.

How to calculate sustained throughput

Sustained completion rate ≈ concurrent analysis tasks ÷ average time per question

For example, 20 concurrent tasks with an average of 30 seconds per question complete about 40 questions per minute. Time per question depends on the model, SQL complexity, data source response, and whether Python runs. Do not derive sustained throughput directly from 10 QPS.

Scaling formula

Concurrent analysis tasks = Worker processes × AT_WORKER_MAX_JOBS
Model concurrency ≥ concurrent analysis tasks × 50%; 1:1 headroom recommended
Application connection peak = 31 + 20 × Worker processes (with Workbook enabled)

The connection formula assumes Workbook is enabled by default. The model-concurrency ratio comes from the validated case (40 tasks with 20 model-concurrency slots); it is not a hard product limit.

• Two Workers: application connection peak 71, plus 10 operations connections gives 81. The default max_connections=100 is sufficient.
• Four Workers: application connection peak 111, plus 10 operations connections gives 121. Leave headroom for PostgreSQL's reserved connections; set max_connections to 150 or more, or DATABASE_BUSY may occur.
• Before adding machines or Workers, confirm the model API concurrency quota. If the model side allows only 5 concurrent requests, 40 backend tasks will still pile up on model calls, showing 429, LLM_RATE_LIMIT, or timeouts.
• DeepSeek's official RPM, TPM, and concurrency quotas vary by account, model, and time window. Use the quota shown in your console. Before purchase, request at least half the number of analysis tasks, preferably 1:1.

Response time and cost per question

Response time depends on the model, SQL complexity, data source response, whether Python runs, and queueing. More complex questions and more tool rounds take longer. Model cost depends on input/output tokens, tool rounds, and the actual unit price. CNY 0.05 is an average for a typical question, not a quote; server, network, delivery, and operations costs are separate.

With 20 concurrent analysis tasks, fast mode completes roughly 40–120 questions per minute, and standard conversation roughly 10–20 per minute. These are estimates from task count; queueing and data source response affect the actual rate.

Accuracy benchmark: measured 99 and threshold 95

Accuracy uses the sample pass rate, not model self-assessment or SQL similarity:

Sample pass rate = human-confirmed correct questions ÷ reviewed questions

This result shows that, with a fixed question set, dataset, and semantic version, 300 governed questions can reach 99%. Treat 95% as the acceptance floor and 99% as the achievable value after sufficient governance; that is more reliable than promising a fixed number. It does not mean any new question or new table will reach 99%, and it does not mean the text of open-ended analysis needs no human review.

Below 95%, we recommend not going live; improve data semantics and the question set, then retest. Between 95% and 99%, start with a pilot, but classify failed questions as “did not understand,” “did not explain clearly,” or “wrong result,” and fix them by category.

Another manufacturing-finance sample used three governed result tables and 20 fixed questions; 20/20 passed. The sample is only 20 questions, so it demonstrates what is achievable after governance, not general accuracy. In the same dataset, an open-ended business insight once contained a counting error in prose (5/8 was written as 6/8). That type of content is outside the fixed question set and must be reviewed by a person before publication.

Accuracy, governance depth, and ontology or semantic-layer modeling have no universal answer apart from your data. Rather than debate methodology in the docs, contact the service team through the official AskTable website for a POC scoping conversation: bring 1–2 data sources, 3–10 core tables, and 20–30 real questions, and agree on which semantics to add, how to build the question set, and what the pass criteria are before committing to a full semantic layer. The docs provide a general checklist; whether you can reach 95% must be measured on your data.

Data-governance requirements for high accuracy

When governance is incomplete, do not start by “switching to a larger model.” Most errors come from unclear field meaning, multiple definitions, mismatched enum values, or wrong relationships.

How to fill value mappings

A user asks for “East China,” but the database stores E01; a user asks for “Mate 40,” but the database stores “HUAWEI Mate 40 Pro 5G.” With mismatches like these, the model can generate the right SQL structure and still filter out every row.

• List high-frequency filter values first: write down the 10–20 most common region, product, status, and channel values, then ask about each in natural language.
• For string columns: enable AI index on the field so abbreviations map to actual values; also record what each enum means in the field description.
• Numeric and date codes: AI index does not process numbers or dates. Explain them in field descriptions, business documents, or a mapping table.
• Limits: 10 indexed fields per data source by default, and 50,000 distinct values per field by default. Private deployment requires AI search to be deployed, and the capability requires an enterprise license.

The index is only an aid. Whether a value mapping works is determined by the result table for the same question.

100-question POC acceptance

How to choose the question set

Take questions from real work, not only demo data. Ground truth comes from business systems, financial reports, or manual calculation. The business owner resolves disputes.

Pass criteria

• All 100 questions are reviewed; coverage is 100%.
• Sample pass rate is at least 95%.
• No permission bypass, no sensitive-field leakage, and no P0 data error.
• Running the same question twice produces a stable definition and result.
• 99% is a measured result after sufficient governance, not an acceptance commitment for any question set.

Two-week schedule

The POC deliverable is not a technical report. It is the 100-question list, ground truth, per-question pass/fail, failure reasons, semantic changes, and a go/no-go conclusion.

Go-live requirements and non-commitments

Confirm before go-live:

• The model supports tool calling, JSON mode, and tool_choice=auto, has a context window of at least 128K, and has at least 35B parameters. A self-hosted model must also support the concurrent analysis tasks, with at least half the task count and 1:1 recommended.
• The private-deployment server can reach the model service. For a fully offline deployment, prepare an internal model service first.
• The data source account is read-only, and network access, allowlists, and query timeouts are configured.
• The business owner, project administrator, and first 5–10 pilot users are named.
• The 100-question acceptance set and ground truth are ready.

Not committed:

• No 100% accuracy, and no guarantee that any new question reaches 99%.
• No 10 completed answers per second; 10 QPS refers to application-layer acceptance.
• No guarantee that every question finishes within 10–30 seconds or 1–2 minutes; response time depends on complexity, model, data source, and queueing.
• No unlimited concurrency; concurrency is limited by Worker task count, model quota, and data source response.
• No fixed price for private deployment; quotes depend on environment, data scale, delivery scope, and service period.
• No replacement for the warehouse, BI platform, ETL, or write-back workflows.
• No identical response time for every data source and every query.

Selection FAQ

Next steps

• Assess accuracy and POC scope: contact the service team with your data sources and real questions, and agree on governance items, the question set, and pass criteria
• First use: follow Ask your first question
• Private deployment: see Private deployment (Docker) and Operations and capacity planning
• Improve data semantics: see Table and field descriptions and Business documents
• Configure models: see Configure models
• Check plans and usage: see Plans and usage and Commercial license