Features
What Xeplr BI actually does
One application, three things you do with it, one model underneath all of them. Each section describes mechanics, not adjectives.
- 1ConnectPoint at the databases you already have
- 2ModelDatasets, and cubes when they are needed
- 3BuildReports and dashboards
- 4PredictTrain on the data you already have
Model
Define it once. Every answer downstream reads from it.
Tables, the joins between them, filters and formula columns — kept as a thing rather than rebuilt per question. This is why two dashboards stop disagreeing about the same number.
- Isomorphic query generation — the SQL you preview in the browser is built by the same compiler that runs on the server
- Joins, filters, formula and ranking columns defined on the dataset, not per report — and datasets can build on other datasets, with cycles refused at save
- Queries on your databases run read-only: Postgres and MySQL refuse writes and stacked statements, and on SQL Server BI is given a read-only login
- The SQL the server compiles is built strictly — values escaped, operators and join types taken off fixed lists, table and column names validated
- Outgrown a live query? Copy the table into a local DuckDB replica and build a pre-aggregated cube over it
- Cubes are sized before they are built — Review gives a verdict only after an exact count over the replica, never from the estimate
- Averages roll up as Sum and Count; distinct counts are stored, but answer only at the cube’s own grain
Report
Grouping, pivots and formulas, then somewhere to put them.
Reports are built on the model, and dashboards carry a model of their own — several datasets and the links between them. Saved reports and dashboards run by id: the server compiles the SQL, and only the reader’s filter values come from the browser.
- Grouping, pivots, subtotals, top-N, running totals and formula columns over any dataset
- The same aggregation code runs over a fetched page in the browser and a streamed result set on the server
- Dashboards join only the smallest set of datasets a widget needs, and are filed in two-level groups
- A dashboard save over someone else’s newer edit is refused, naming who made it and when
- Conditional formatting on dashboard widgets as a rule set
Predict
From "what do you want to know" to a trained model.
Choose an objective and it already knows what it needs. Point each input at a column you have, and train — no algorithm to pick and nothing to tune. Sales forecasting ships today, running on Prophet; the objective list is a registry rather than a hard-coded feature.
- Objectives declare their own inputs, marked required or helpful
- Feature maps are validated before training — a run fails on a missing input immediately, not after Python starts
- Predictions land in a real table that registers as an ordinary dataset
- History and forecast sit in one table, so a single chart shows actual against predicted
Underneath
True everywhere in the product
Multi-tenant from the first row
Company and workspace are tenancy levels enforced at the model layer. A query without its tenant context is refused rather than quietly returning another tenant's rows, and a request for a workspace the caller does not belong to gets a 403.
Access is a catalog, not a guess
Roles are granted groups such as reports:view, and every route and menu item is registered with the group that governs it, so who can reach what is answerable from the catalog. Company and workspace membership is checked on every request.
Scheduling is one system
Data moves, file loads, replica loads and cube builds are all actions on the same job runner, so a schedule is a job rather than a field on a table. Workflows chain those jobs and actions into steps, in the same application.
Four email providers, one call
SMTP, AWS SES, Azure and Brevo behind a single signature in @xeplr/email — switching is configuration. Xeplr BI's own settings cover SMTP and Brevo today.
Charts are not wrapped
The chart layer builds an Apache ECharts option and hands it over, so anything ECharts can do remains reachable.
Swappable presentation
Every UI package splits model, controller and design. Take the finished page, keep the hook and bring your own design, or use the model with no React at all.
Bring a schema you think is difficult
The demo is most useful on the table that is currently too slow to query.