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 DuckDB replica
Source tables are copied into one DuckDB 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.
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.