How to Build a Sales Forecast Model in MindsDB

October 24, 2026

Building a sales forecast in MindsDB takes three SQL statements: create a model on your sales table, check its accuracy score, and select from the model for future periods. The prerequisite is a table with one date column and one numeric column, at least 24 rows of history.

MindsDB’s time-series engine picks its own algorithm underneath, so you are not choosing ARIMA versus Prophet. That is a fair trade: less control, much less setup.

What table shape does MindsDB need?

This is where most forecasts fail. Your table must have:

Column	Type	Example
order_date	date, monthly	2026-01-01
revenue	numeric	48210.55
region	categorical (optional)	EU

The date column must be unique per series. If your table has one row per order, aggregate first — MindsDB will not do it for you, it will just produce noise.

CREATE VIEW shop.monthly_sales AS (
  SELECT DATE_TRUNC('month', order_date) AS order_date,
         SUM(total) AS revenue
  FROM shop.orders
  GROUP BY 1
);

How do you train the model?

Three parameters shape the result. Getting them wrong produces forecasts that look plausible and are useless.

CREATE MODEL mindsdb.sales_forecast
FROM shop (SELECT * FROM monthly_sales)
PREDICT revenue
ORDER BY order_date
WINDOW 12
HORIZON 3;

WINDOW 12 means each prediction looks back 12 rows. For monthly data that is a year of seasonality. Set it to 6 and you lose the annual pattern.
HORIZON 3 forecasts three periods ahead. Do not forecast 12 months from 24 rows of history.
ORDER BY is mandatory. Without it training either fails or silently shuffles.

Training status is visible via SELECT * FROM mindsdb.models WHERE name='sales_forecast'; and takes a minute or two for a table this size.

How do you check accuracy before trusting it?

MindsDB reports an accuracy figure when training finishes, but that number is computed on a holdout split it chose. Run your own backtest.

Train on data through a cutoff date, say 18 months.
Forecast the next 3 periods using WHERE order_date > '2026-01-31'.
Compare against actuals with mean absolute percentage error.

A 15-20% MAPE on monthly revenue with strong seasonality is a decent model. Anything above 35% means your input table is too noisy — look for a big outlier month or a product change that resets the series.

How do you get the actual numbers out?

For future periods, query with a date beyond your data:

SELECT order_date, revenue
FROM mindsdb.sales_forecast
WHERE order_date > '2026-10-31'
AND order_date <= '2027-03-31';

The result includes a confidence interval per row. Report the interval, not just the point estimate. Sales leaders who get a single number treat it as a commitment; those who get a range treat it as a plan.

What breaks forecasts in practice?

Four things, all common.

Aggregating by the wrong date. Use order date, not ship date. Ship dates shift at quarter-end and inject fake seasonality.

Mixing currencies. A table with EUR and USD rows produces a series that jumps with FX. Convert first.

Including the current partial month. A month that is 40% elapsed drags the model’s trend down. Filter to complete periods only.

Ignoring structural breaks. A price increase in month 14 changes the series. Either model from the break or add a categorical column for pre/post.

Is MindsDB better than a spreadsheet for this?

For one series, honestly, a spreadsheet forecast function is faster and easier to explain. MindsDB wins when you have many series — 50 SKUs, 20 regions — because you write one query and get all of them, and retraining is a scheduled job rather than a manual rebuild.

It also wins on refresh frequency. If your forecast needs to update weekly from a live database, doing that in a spreadsheet means export, paste, recalc. That manual step is what pushes teams to a platform.

Where MindsDB does not win: explanation. Your CFO will ask why February is forecast low, and MindsDB will not tell you. Expect to do that reasoning yourself.

How do you keep it running?

Schedule retraining with RETRAIN mindsdb.sales_forecast; on a weekly or monthly cadence, depending on how fast your data shifts. Monthly sales data does not need daily retraining, and retraining daily just wastes compute and introduces model churn.

Keep one model per series group and name them consistently. Six months in, unlabeled models in a shared instance become a junk drawer.

Key Takeaways

MindsDB forecasting needs a date column, a numeric target, and 24+ rows of clean history per series.
Use WINDOW 12 on monthly data to capture a full year of seasonality; HORIZON should stay short.
Always run your own backtest — the built-in accuracy number uses a split you did not choose.
15-20% MAPE is realistic for seasonal monthly revenue; above 35% means the input table is dirty.
For one series a spreadsheet is fine; MindsDB pays off at 50+ series with automated refresh.

More details on batch prediction and deployment are on the MindsDB profile at iAIFeed.

Tags:

mindsdb