Live demo

See what Intellrise returns, before you sign up.

Four charts built on a 12,259-row synthetic e-commerce dataset. Every chart below shows the exact SQL it runs and the exact numbers it returns. No account, no AI key, no mockups.

Connect your own database See the dataset

tables, queried with joins

12,259

rows of sample data

pre-built charts

signups required

The dataset

Five tables, one year of orders

Orders span 2024-01-01 to 2024-12-30. This is a synthetic sample dataset generated for demonstration — not a customer's data. The queries and results are real; the business is not.

Table	Rows	What it holds
demo_orders	3,000	One row per customer order: order date, customer, payment method, status, shipping fee, discount and total amount.
demo_order_items	5,494	Line items — one row per product within an order, with unit price, quantity and subtotal.
demo_payments	2,845	Payments collected against orders: amount, settlement date, status and channel.
demo_customers	800	Customer directory, including the state each customer is in.
demo_products	120	Product catalogue with category, brand and unit cost price.
Total	12,259

Cancelled orders are excluded

Order status is one of paid, shipped, delivered, cancelled. Every query on this page filters out cancelled orders, so nothing below counts revenue that never happened.

Dates arrive as text, so the SQL casts them

The CSV loader does not parse dates, so date columns land as text, and the schema Intellrise records says so. That is why the first query casts to TIMESTAMP before calling strftime instead of failing on a type error — the same constraint any correct query has to respect here, whoever writes it.

Question, query, result

The four charts, end to end

Each block is one pinned chart from the demo dashboard: the question it answers, the SQL it runs, and the values it returns.

Who wrote these queries

We wrote these four queries by hand when the demo was seeded. This page is a record of what the product returns, not a recording of the model writing SQL — and you should not have to guess which one you are looking at. The queries and the numbers are real: each one ran against the CSVs linked above and the values below are what came back, copied verbatim. What was not automated is the step that turned a question into that SQL — a person did that here. Since 19 August 2026 that step is on the page too: under each chart is the SQL the default model wrote when it was asked the same question, unedited, next to where it disagrees with ours. It disagrees on three of the four. Judge us on that; it is still not the test that should decide it, because the translation is only worth watching against a schema you recognise — yours. That starts when you connect a source, on a 14-day Pro trial that takes no card.

This is the query the chart runs, with one cosmetic difference: each CSV source registers in DuckDB under a generated alias, so in your own workspace `demo_orders` appears as `demo_orders_` plus a six-character source id.

Question 01

How did revenue move month by month in 2024?

Pinned on the demo dashboard as Monthly revenue trend

SQL executed

SELECT strftime(CAST(o.order_date AS TIMESTAMP), '%Y-%m') AS order_month,
       ROUND(SUM(o.total_amount), 2) AS revenue
FROM demo_orders o
WHERE o.order_status <> 'cancelled'
GROUP BY 1
ORDER BY 1
LIMIT 24

Monthly revenue trend

Drawn from the query result above

Scroll the chart sideways to see every bar. Month against revenue. Amounts are unitless in the sample data.

Revenue holds a narrow band across the year: February is the low month at 37,714.84 and September the high at 53,445.30 — about 42% above it. No month runs away from the rest.

What the model wrote when we asked it the same question

gemini-3.1-flash-lite · 19 August 2026 · shown as a plan you approve before it runs

What it said it was going to do: “I'll calculate the total monthly revenue for 2024 by summing the order amounts and grouping them by month.”

If you do not read SQL, that sentence plus “What came back” and “Where it differs from ours” further down are your check — here and under every chart below, you can run this whole comparison without opening a single query block. We should say the harder half of that out loud: “you can read the SQL and refuse it” is not a guarantee you can use if SQL is not a language you read, and most people who need this tool most cannot. What is left for you is narrower and still real — a stated intention, the numbers it returned, and a named difference from a query a human wrote. Be clear about where that stops: the differences below are visible without reading any SQL, because they show up in the totals and in which product names make the list. The reasons for them are not. We had to read the queries to find out why, and if that step matters to you and you cannot take it, then this is a job you want a person who reads SQL to check once — not a reason to trust the answer more.

SQL the model wrote — verbatim

SELECT
    strftime(order_date::DATE, '%Y-%m') AS month,
    ROUND(SUM(total_amount), 2) AS total_revenue
FROM demo_orders_1a2b3c
WHERE order_date BETWEEN '2024-01-01' AND '2024-12-31'
GROUP BY 1
ORDER BY 1 ASC

What came back: Ran. Twelve rows, one per month, and the same shape as ours — February the low month, September the high one.

Where it differs from ours: Every month comes back higher. The year totals 597,387.69 against our 570,211.28: 27,176.41 more, which is exactly the value of the 155 cancelled orders our query excludes and its query does not. Add AND order_status <> 'cancelled' to the model's query, change nothing else, and all twelve months match ours to the cent. One further thing we saw asking this three times: in one run the model left the ::DATE cast out, and that query does not run at all — DuckDB refuses strftime on a text column with “Could not choose a best candidate function”. The cast this page explains further down is not a stylistic detail; it is the difference between a chart and an error.

Question 02

Which states bring in the most revenue?

Pinned on the demo dashboard as Revenue by state

SQL executed

SELECT c.state AS state,
       ROUND(SUM(o.total_amount), 2) AS revenue
FROM demo_orders o
JOIN demo_customers c ON c.customer_id = o.customer_id
WHERE o.order_status <> 'cancelled'
GROUP BY 1
ORDER BY 2 DESC
LIMIT 20

Revenue by state

Drawn from the query result above

Scroll the chart sideways to see every bar. State against revenue. Amounts are unitless in the sample data.

Six states appear in the sample. Selangor leads at 109,983.14 and Sabah trails at 78,134.42; no single state accounts for more than a fifth of the year's revenue.

What the model wrote when we asked it the same question

gemini-3.1-flash-lite · 19 August 2026 · shown as a plan you approve before it runs

What it said it was going to do: “I will calculate the total revenue per state by joining the orders and customers tables.”

Not a SQL reader? Skip the block below and read the two lines after it.

SQL the model wrote — verbatim

SELECT
    c.state,
    ROUND(SUM(o.total_amount), 2) AS total_revenue
FROM demo_orders_1a2b3c o
JOIN demo_customers_4d5e6f c ON o.customer_id = c.customer_id
GROUP BY c.state
ORDER BY total_revenue DESC
LIMIT 10;

What came back: Ran. Six states, in exactly our order.

Where it differs from ours: The ranking survives; the amounts do not. Johor comes back 2.43% high, Kuala Lumpur 7.15% high, for the same reason — cancelled orders are still counted. A reader who quotes the ranking is fine and a reader who quotes a number is wrong, which is the harder of the two failures to notice.

Question 03

What are my top 10 products by revenue?

Pinned on the demo dashboard as Top 10 products by revenue

SQL executed

SELECT p.product_name AS product,
       ROUND(SUM(oi.subtotal), 2) AS revenue
FROM demo_order_items oi
JOIN demo_products p ON p.product_id = oi.product_id
JOIN demo_orders o ON o.order_id = oi.order_id
WHERE o.order_status <> 'cancelled'
GROUP BY p.product_id, p.product_name
ORDER BY 2 DESC
LIMIT 10

Top 10 products by revenue

Drawn from the query result above

Scroll the chart sideways to see every bar. Product against revenue. Amounts are unitless in the sample data.

The leader, Action Camera 4K, contributes 11,680.75 — about 2% of the year's line-item revenue. This catalogue spreads revenue widely rather than concentrating it in a few products.

What the model wrote when we asked it the same question

gemini-3.1-flash-lite · 19 August 2026 · shown as a plan you approve before it runs

What it said it was going to do: “I will join the orders items and products tables to calculate the total revenue per product and list the top 10.”

Not a SQL reader? Skip the block below and read the two lines after it.

SQL the model wrote — verbatim

SELECT
    p.product_name,
    ROUND(SUM(oi.subtotal), 2) AS total_revenue
FROM demo_order_items_2b3c4d oi
JOIN demo_products_5e6f70 p ON oi.product_id = p.product_id
GROUP BY p.product_name
ORDER BY total_revenue DESC
LIMIT 10;

What came back: Ran. Ten products.

Where it differs from ours: Here the same 4.77% changes the answer rather than the number: Kettlebell 8kg is in our top ten and not in the model's, and Running Shorts is in the model's and not in ours. Cancelled orders again. This is the case to keep in mind — a difference small enough to look like rounding is large enough to swap a name in a list someone acts on.

Question 04

How much have we actually collected, split by payment channel?

Pinned on the demo dashboard as Collected revenue by payment channel

SQL executed

SELECT pm.channel AS payment_channel,
       ROUND(SUM(pm.amount), 2) AS collected_revenue
FROM demo_payments pm
JOIN demo_orders o ON o.order_id = pm.order_id
WHERE pm.payment_status = 'success' AND o.order_status <> 'cancelled'
GROUP BY 1
ORDER BY 2 DESC
LIMIT 10

Collected revenue by payment channel

Drawn from the query result above

Scroll the chart sideways to see every bar. Payment channel against collected revenue. Amounts are unitless in the sample data.

Collection is close to even across the four channels: COD 148,596.42 and FPX 148,352.19 are within 250 of each other, with Credit Card lowest at 135,130.85.

What the model wrote when we asked it the same question

gemini-3.1-flash-lite · 19 August 2026 · shown as a plan you approve before it runs

What it said it was going to do: “I will join the payments and orders data to sum the collected amounts by payment channel.”

Not a SQL reader? Skip the block below and read the two lines after it.

SQL the model wrote — verbatim

SELECT
    channel,
    ROUND(SUM(amount), 2) AS total_collected
FROM demo_payments_3c4d5e
GROUP BY channel
ORDER BY total_collected DESC

What came back: Ran. Four channels, identical to ours to the cent — this one it got right, by writing no status filter at all.

Where it differs from ours: We asked this question three times. The other two runs invented a payment_status value that is not in the data — 'Paid' in one, 'Completed' in the other — and both returned zero rows out of 2,845 payments, every one of which has the status success. Given that empty table, the product's own narration step wrote: “It looks like there are no completed payments recorded in the system.” That is the failure worth knowing about: not an error, a confident wrong answer. Note too that the plan text above says it will join payments and orders, and the query joins nothing.

Why the model got it wrong, and what stops it

Why it goes wrong is worth more to you than the fact that it did. A CSV registers with column names and types and nothing else. Nothing the model is shown says that 155 of these 3,000 orders are cancelled and should not count as revenue, or that payment_status only ever holds success. It is inferring business meaning from column names — and where it inferred wrong here, it did not fail loudly, it returned a confident number that is 4.77% too high. Two things are true alongside that. Three of these four came back as a plan you approve before anything runs, so the SQL you see is the SQL you can reject. And when you tell it what a column means, it offers to save that definition against the source so the next question starts from it. Neither makes the first guess correct. Both are why the test that decides this for you is your schema, not ours.

The part this page can't show you

So we ran it against a database nobody had tidied

A clean five-table sample is the easy case. The question worth answering is what happens on the kind of database you actually run — so we built one to be awkward on purpose and pointed Intellrise's schema learning at it. Here is the whole result, including the half that does not flatter us.

30 tables, 253 columns, 8,337 rows, 44 foreign keys — and not one column comment. Column names like cust_no, amt_ex_tax, qty_shp.

What it got right, unprompted

Flagged del_flg as a soft-delete marker. Miss that and every revenue number you produce is too high.
Called ord_ln.total an “Extended line total” — a line subtotal, not an order total. Those get summed together by mistake constantly.
Sorted the junk from the live tables on its own: cust_mstr_bak as a backup, ord_hdr_tmp as import staging, sys_audit_log_old as an old audit log.
Worked out from three sample rows that payments join to invoices through a text field — pymt_hdr.ref_no holds “INV” plus the invoice number. There is no invoice column on that table to give it away.

What it got wrong — and did not flag

It got two date columns backwards. It described order_date as “Date of the order” and dt_ordered as “Timestamp of order entry”. It is the other way round — order_date falls on or after dt_ordered on all 400 orders.
It said nothing about tax. ord_hdr.amount excludes it, invc_hdr.amount includes it, and the invoice runs a median 1.0765× the order. Both were described as a total amount.
It missed a hundredfold scale difference. comm_pct holds 0.02 to 0.04; rate_pct holds 4.00 to 12.75. Both came back described as a percentage.

None of those three facts are in the schema or the sample rows, so they cannot be inferred from them — they have to be told. Whether a column is tax-inclusive, which date counts, and whether a rate is stored as 0.02 or 2.00 are things a person has to say once. What differs between tools is what happens to that sentence afterwards. In Intellrise the correction is written to your data source's own row in our database — a metadata_cache column — rather than into a conversation, and every new chat session reads it back from there.

To be exact about how well we know that, because the rest of this page is measured and this part is not: we have verified it by reading our own code, not by running a two-week test in front of you. Until 17 August 2026 this paragraph carried a limit we had published against ourselves — asking Intellrise to re-learn a source's schema replaced that whole set of descriptions, hand-written corrections included. That one is fixed: a re-learn now rewrites what the model wrote and leaves what you wrote, including on tables the new pass came back without. One case is still open, and it is why this paragraph stays: on a Google Sheets source, changing which tabs it reads clears every description on every tab, including the tabs you kept. We found that one ourselves rather than waiting for you to lose a definition over it, and it is a bug we have not shipped the fix for yet — so if you are teaching a Sheets source, add the tabs you want before you start writing definitions.

We have not published a side-by-side against other assistants, so we are not going to tell you what they do. The test takes two minutes and you can run it on whatever you use today: tell it what one awkward column means, open a fresh chat, and ask again.

Two limits worth knowing before you try it. The first pass will get some business meanings confidently wrong, as above, and the product does not yet mark which ones it was unsure about — so read the schema notes once after connecting. And every source you connect shares one workspace, so if you are connecting several clients' databases there is no wall between them. That sentence is about separation, not billing, so here is the mechanism rather than a link: each question's schema context lists the tables and columns of every connected source, and a single query can join across them. That is deliberate — cross-source questions are the reason the product exists — but it means one account gives you no per-client boundary, and nothing in the product will stop a question about client A from reading client B's tables. If a client needs strict separation, that is a separate account, not a setting. The cost of going that way, since we are the ones who sent you down it: another $29/month per isolated client, each with its own login and its own AI key, and no agency bundle in our plans today. And we do not publish a data processing agreement today — if your client's review asks for one, that is a conversation to have before you connect anything. The full arithmetic is on the pricing page. What this test does not tell you is whether we can reach your database at all — that one is about your network and the account you hand over, and it is answered in database requirements and what we ask for and why.

Straight answers

What this page is, and what it isn't

What it is

Static output from real queries. The SQL shown is the SQL each chart runs, and the values are what it returned against the committed sample CSVs.
Proof the dashboard path needs no AI model: those charts render for an account with no AI provider key at all.

What it isn't

Not a live query console. This page is pre-rendered HTML; it does not connect to a database and you cannot type a question into it.
Not AI-written SQL, for the four charts. Those four queries were written by hand for this page, and they are the ones the charts render. The model's own answer to the same four questions is printed underneath each chart, labelled and unedited — it is shown so you can compare it, not because it is what produced these numbers.
Not real customer data. It is a synthetic sample dataset, and the amounts carry no currency unit.

To ask your own questions of your own database, you need an account and your own AI provider key. Intellrise is bring-your-own-key on every plan, so AI usage is billed by your provider, at your provider's rates, and never by us. This page needs neither — it is static output, so you can judge the SQL and the charts before creating anything.

Questions about this demo

Do I need an account to see these charts?

No. This page is static HTML built from query results — there is no login, no form and no AI key involved in viewing it.

Is this real customer data?

No. It is a synthetic sample e-commerce dataset generated for this page. The queries and the results are real; the underlying business is not.

Did the AI write these queries?

Not the four the charts run — we wrote those by hand when the demo was seeded, and the page says so above the first one rather than leaving you to infer it. The AI's own version is also on the page, clearly separated: on 19 August 2026 we asked gemini-3.1-flash-lite, the model a Gemini key gets by default, the same four questions through the product's own prompt and tools, and printed what it wrote unedited. It disagreed with us on three of the four, always the same way — it counted cancelled orders as revenue, because nothing in a CSV's schema tells it they exist, which puts the yearly total 4.77% high and swaps one product out of the top ten. The numbers under the charts are the hand-written queries' output, copied verbatim.

Can I load this dataset into Intellrise?

No — Intellrise connects to data you already have. There is no sample dataset to import: you point it at your own Postgres, MySQL, SQL Server, Redshift, BigQuery, Snowflake or Databricks, or upload a CSV or Excel file, or connect a Google Sheet. This page exists so you can judge the output before doing any of that.

Do I need an AI provider key to use Intellrise?

Yes. Intellrise runs on your own provider key — Gemini, OpenAI, Anthropic, DeepSeek or MiniMax — so the questions you ask go through your own account rather than ours. This page needs no key because it is static HTML built from results we ran in advance.

Why are the amounts shown without a currency?

The sample dataset stores amounts as plain numbers with no currency unit recorded, so labelling them with a currency symbol would be inventing information the data does not contain.

Why do the queries cast dates before formatting them?

CSV sources load without date parsing, so date columns arrive as text, and the schema Intellrise records says so. That is why the SQL casts to TIMESTAMP before calling strftime instead of failing on a type error — the same constraint any correct query on this data has to respect, whoever writes it. The four chart queries were written by hand when the demo was seeded; the page says so above the first one. The model met the same constraint when we asked it the same questions on 19 August 2026 — it wrote order_date::DATE — except in one of three runs, where it omitted the cast and the query would not run at all.

Now point it at your own data.

Intellrise works from either kind of data. If your numbers live in a spreadsheet, a Google Sheet, a CSV or an Excel file connects directly. If you run a database — Postgres, MySQL, SQL Server, Redshift, BigQuery, Snowflake, Databricks — it connects to that. Either way it runs on your own AI provider key, so the questions go through your account, not ours.

Get started free Talk to us

Every new account starts on a 14-day Pro trial with no card. After it lapses, the free tier stays free.