Apache Superset as the BI Layer Over a Payments Ledger
Canned reports answer the questions you already knew to ask. For everything after that — a new chart, a fresh cut of last quarter, a dashboard for a specific stakeholder — you want a proper business-intelligence tool. KibiPay runs Apache Superset as that layer, wired carefully so it can explore the payments data without ever endangering it.
Its own brain, a curated view of the data
Superset needs a metadata database to store its own dashboards, charts and users. That lives in a dedicated superset database, kept entirely separate from the payments schema so BI state and payment state never share a table. Separately, Superset is pointed at the analytical datasource registered as "FSAOL Postgres (reporting)" — the payments data it is actually allowed to chart.
The deployment runs a single web pod on port 8088 with a Recreate rollout strategy. That single-writer choice is deliberate: Superset's metadata store does not want two pods racing to migrate or write it, so we trade horizontal scale for correctness on the control-plane component and let the heavy query load fall on the database, not the web tier.
Bootstrapped, not hand-built
Nothing about the install is a snowflake. An init container runs superset db upgrade to migrate the metadata store, superset fab create-admin to create the admin account, superset init to set up roles, and then registers the reporting datasource — every time, reproducibly, from configuration. Feature flags enable DASHBOARD_RBAC (so dashboards can be scoped to the right roles) and template processing; secrets like the app secret key and admin password come from a Kubernetes secret, never the image.
Seeded dashboards, not a blank canvas
A blank BI tool is intimidating and gets ignored. A seed script uses Superset's REST API to create datasets over the core tables — payments, settlement_run, recon_break and reversal — and then builds a starter set of charts:
- Payments by scheme — a pie over the rail mix.
- Payments by status — a distribution bar across the lifecycle states.
- Settled value by currency — summed amount filtered to
SETTLED, the money that is truly final. - Reconciliation breaks by kind — a pie over the break taxonomy from the recon engine.
Those roll up into a "Payments overview" dashboard so a new user lands on something useful and starts editing, rather than staring at an empty workspace.
Reachable, but fenced
Superset is exposed on its own hostname (bi.kibipay.com) behind TLS, and the console links to it directly as a "BI (Superset)" menu item that redirects out to that host. A network policy allows only the intended traffic to reach it. The result is a self-serve analytics surface that sits over the ledger — reading the same replica-backed data as the ad-hoc SQL platform — without becoming a new way to touch production writes.
Reports for the known questions, ad-hoc SQL for the one-off, Superset for the ongoing dashboard: three tools, one carefully guarded read path.
The operational shape
The way Superset is run says as much about the design as what it charts. It runs as a single web pod with a recreate-on-deploy strategy, deliberately trading horizontal scale on the web tier for a single, unambiguous writer of its own metadata — a BI tool's dashboards and users are state you don't want two pods racing to migrate. Its metadata lives in its own database, entirely separate from payments data, so a Superset upgrade can never touch a payment. It reaches the payments data only through the registered reporting datasource, and dashboard-level role-based access control is switched on so a given dashboard can be scoped to the right audience rather than exposed to everyone with a login. It's published on a dedicated hostname behind TLS and fenced by a network policy, and the console links to it as a first-class menu item that redirects out to that host. The seeded charts and the "Payments overview" dashboard mean a new analyst starts from something real and edits it, rather than facing an empty tool and giving up — the fastest way to make a BI investment worthless. The overall effect is a self-serve analytics surface that anyone with the right role can explore freely, sitting over the ledger with none of the ways a curious analyst might otherwise endanger production data.