Xeplr Pro Suite
Xeplr BI
Datasets, reports and dashboards over the databases you already run, with cubes for the tables too big to query live. One model and one SQL compiler underneath all of it, so a preview and a production run cannot disagree about the same number.
Every report defines the metric again
When each report builds its own idea of "active customer", the definitions drift and the meeting becomes an argument about whose number is right. More dashboards make that worse, not better.
How it works
A model, not a pile of extracts
Tables, the joins between them, filters, formula columns and ranking columns, kept as a dataset and reused. A dataset can build on another dataset on the same source, and a cycle is refused when it is saved.
One compiler for preview and production
The SQL the builder previews in the browser is generated by the same code the server runs. Saved reports and dashboards run by id — the server reads the configuration and compiles the query, and only filter values come from the reader.
Read-only on your databases, SQL built strictly
Previews, report grids and dashboard aggregation connect read-only, so Postgres and MySQL refuse writes and stacked statements. The SQL the server compiles escapes values for the dialect, takes operators, join types and window functions off fixed lists, and validates every table and column name.
Reports computed once, in two places
Grouping, pivots, subtotals, top-N, running totals and formulas come from one engine that reduces a fetched page in the browser and the full result stream on the server. Memory grows with distinct cells, not rows, and a run past 50 MB is refused plainly rather than taking the server down.
Dashboards with their own model, filed in groups
A dashboard carries several datasets and the links between them, and joins only the smallest set a widget needs. Boards are filed in two-level groups, and a save over someone else’s newer edit is refused, naming who made it and when.
Cubes on a local columnar replica
Source tables are copied into one columnar warehouse per workspace — upserted or replaced, never appended — and joined there. The design steps show no size figure; Review gives a verdict only after an exact count over the replica. A build writes a new versioned file, so a reader never sees a half-built cube, and a failed refresh keeps the old copy.
Averages roll up, distinct counts do not
A cube stores an average as Sum and Count and divides when it rolls up. A distinct count is stored and answers at the cube’s own grain, but is never added up to a coarser one — that would over-count.
Workflows, jobs and problems inside
The workflow engine and its step builder are mounted inside BI with their own database. Data moves, file loads, replica loads and cube builds are jobs on one scheduler, and failed or stuck work lands on a single Problems list.
Measured, not assumed
Dashboards read cubes from a columnar store rather than a row store like Postgres. We tested both on the same 2 crore (20 million) row orders table: one table, a fixed seed, each database in its own container with 4 CPUs and 6 GB, and Postgres 16 tuned rather than left on defaults. Times are the median of 5 warm runs.
| Query | Postgres | Columnar cube | Faster |
|---|---|---|---|
| Month × region, 1 year | 3.0 s | 154 ms | 20× |
| Month × region × channel × status, 1 year | 4.1 s | 267 ms | 15× |
| Month × city × store, top 500 | 9.1 s | 300 ms | 30× |
8× less disk
419 MB against 3.5 GB for the same rows, indexes included.
3× less memory
Peak 1.6 GB against 5.5 GB during the run.
Up to 8× more from time order
Cubes are written in time order, so a one-month filter skips most blocks: 5 ms against 40 ms.
Fetching one order by its id is faster in Postgres: 0.7 ms against 2.4 ms. So each engine keeps its own job: cubes for dashboards, and your own Postgres or SQL Server for looking up single records.
What it does not do yet
Current as of the product readme. If something here matters to you, ask — some of it is next.
- Run results are held in memory for ten minutes by the API process that ran them, so the API runs as a single process today.
- SQL Server has no read-only connection mode. Give BI a login with only db_datareader on source databases.
- Custom formula text is not validated — it is SQL its author is trusted to write.
See it against your own data
A demo runs on your schema, not a sample dataset. Thirty minutes, no deck.