Can you replace a $100k Sisense stack with open-source alternative & AI agents?

Like a lot of companies, you pay for Sisense. The number came out of a negotiation rather than a price list (buyers on Reddit report $35,000 a year for 35 to 40 self-hosted embedded users and $60,000 for 15 full users (opens in a new tab), and another described an "85% discount off list" (opens in a new tab) that "came off as disingenuous"), and by the time you add the servers, the plugins and the people who keep it alive, the whole stack is a six-figure line item. Spending the money is still the easier part. Once you have bought it, most of your week goes on the unglamorous stuff: nursing ElastiCube builds that run long or fail overnight, choosing between cubes and Live models when, as one long-time analyst put it (opens in a new tab), cubes "break, and inexplicably fail/fix themselves" while Live models "take forever to load"; squinting at a data model view that shows no cardinality and treats every join as two-way; and keeping a stack of third-party plugins compatible through each upgrade, because fonts, parameters and precise layouts all need JavaScript or somebody else's add-on.

Keeping the tool running and reliable is one job, and making it appealing enough that people actually use it is another. Sisense dashboards sit on a snap grid, so adding one widget near the top pushes everything below it out of place, and the result looks like every other Sisense dashboard. If you work in data, you know how quickly business users abandon a well-built dashboard for Excel when that happens. The numbers drift once they leave the tool, but at least people get their number fast, in a format they understand. The top comment in the thread above, with 71 upvotes, came from an analyst who resigned six months into a new job and "cited Sisense as the reason."

So you look at Sisense alternatives (opens in a new tab) that are more affordable or more powerful, such as Power BI, Metabase or Holistics, and the pricing story usually improves. The day-to-day story improves less than you hoped, because every BI tool has its own grid, its own chart list and its own limits on what an embedded page can do. As long as you build inside the constraints of a BI tool, you end up back in the same place, with dashboards that are correct, look generic, and get exported to a spreadsheet anyway.

The wishful thought every data team has had

At some point, every data team has the same wistful conversation: maybe we should just build our own analytics with our coding agents and cancel Sisense.

The idea sounds less silly than it did a year ago. Claude Code with Opus 5.5 can now work inside your repos, use your tools and run a query to check a number before it answers. It can produce an HTML dashboard that looks far better than a Sisense widget grid, with pixel-level layouts and custom interactions that would have taken a plugin and a week of JavaScript before. Your business users have already noticed. Some of them now one-shot a dashboard in Claude on a Tuesday afternoon, and (accuracy aside) the experience is fast, easy and good-looking enough that they keep coming back to it.

So is that enough? Can a coding agent and an open-source stack replace a $100k Sisense stack with something more affordable and better looking?

A BI tool is more than charts and dashboards

The charts were never the whole product. Underneath every BI tool, including Sisense, sits a foundation that most teams never think about because the vendor bundled it in:

The apps on top are the part data teams want to customise. The foundation underneath is the part they have to reinvent and maintain the moment they build their own, and it is where home-grown BI projects get expensive. Teams that start with one agent-built app soon find themselves adding a Postgres database and a caching layer to each app so pages load quickly (rebuilding a small ElastiCube by hand, in effect), rewriting the permission logic for every new page, and discovering that the agent wrote a slightly different revenue calculation for each one.

Inconsistent metrics do the most damage. When an agent queries raw tables, it decides what each metric means and writes fresh SQL for every app, so it can average a rate that should be recomputed, or join a table that double-counts a fee, and the chart still renders. After a few months, two apps show two different totals and nobody can tell which is right, and the hidden join logic you were glad to leave behind in the Sisense model view comes back, scattered across a dozen apps.

Trust or freedom, until now

Data teams have been choosing between two imperfect options.

Off-the-shelf BI gives you governed numbers in a fixed frame. Custom-built BI gives you any frame you like with numbers nobody can vouch for. Most teams end up trading one for the other, which is why the Sisense contract survives even after half the company has moved its real work into Claude.

anfra: one governed backend for every data app your agent builds

anfra (opens in a new tab) is an open-source framework for building custom data apps, designed to sit in the top-right corner of that table: a flexible front end on governed data. The simplest way to describe it is a single data backend for every internal app your team builds (opens in a new tab). Your data team defines metrics once, in code, and reviews every change, and every app your coding agent builds asks for those metrics by name.

There are two ways in, and both land on the same definitions:

1. Build. A coding agent such as Claude Code, Codex or Cursor writes an app (plain HTML and JavaScript) with the anfra SDK. The app never writes SQL. It asks anfra Server for active_accounts by plan, and anfra compiles that request into SQL against your definitions and runs it on your warehouse.
2. Ask. Any agent connects through anfra's MCP server, reads your models, and learns what a metric means before it writes anything, so the analysis a business user runs in a chat uses the same definition as the app on their screen.

Underneath both sits your warehouse (Snowflake, BigQuery, Databricks, Redshift, ClickHouse, PostgreSQL, DuckDB and others). anfra runs the SQL there and keeps no copy of your data, so there is no cube to build, no build schedule to babysit and no server sized for memory.

Setup takes one prompt

anfra installs as a single binary for Linux and macOS, and its agent skills teach your coding agent how to write models and build apps:

curl -fsSL https://anfra.ai/install.sh | bash
anfra agent setup

From there, a single prompt gets you a working app:

Set up anfra in this folder, connect to my product database. Build me an account health data app. Be creative with your app. Use the anfra-build-data-app skill.

Joins and metrics you can read

The complaint Sisense users make most about the data model is that they cannot see what it does. In anfra, a dataset declares its joins in code with the direction written out. In relationship(a > b, true), a is the many side and b is the one side, so anyone reading the file, or reviewing the pull request, sees the cardinality of every join:

Dataset product_usage {
  label: 'Product usage'
  data_source_name: 'warehouse'
  models: [events, accounts, plans]
  relationships: [
    relationship(events.account_id > accounts.id, true),
    relationship(accounts.plan_id > plans.id, true)
  ]
 
  metric active_accounts {
    label: 'Active Accounts'
    type: 'number'
    description: 'Accounts with at least one event in the period. Use this for engagement questions; billing uses paying accounts instead.'
    definition: @aql count_distinct(events.account_id);;
  }
 
  metric events_per_account {
    label: 'Events per Account'
    type: 'number'
    definition: @aql count(events.id) / count_distinct(events.account_id);;
  }
}

Agents pick the right metric far more often when a description says when to use it, especially when your company has two versions of the same idea (active and paying, gross and net), so it pays to write those sentences while you are moving the formulas out of Sisense widgets. Your agent can draft the models and metrics, and your team reviews them in a pull request like any other code change.

The app asks for metrics by name

Here is a page with active accounts by plan and a weekly trend, where a click on a plan filters the trend:

const byPlan = app.createQuery('byPlan', {
  dataset: 'product_usage',
  aql: `explore {
    dimensions { plan: plans.name }
    measures { active: active_accounts }
  }`,
})
const weekly = app.createQuery('weekly', {
  dataset: 'product_usage',
  aql: `explore {
    dimensions { week: events.created_at | week() }
    measures { active: active_accounts, per_account: events_per_account }
  }`,
})
 
app.mapCrossFilter(byPlan, weekly)

The page names a dataset and asks for active_accounts. It never redefines the metric and never writes SQL, so the number means the same thing in this app, the next app and the chat a business user opens tomorrow. Filters, date drills and cross-filters are built-in patterns in the SDK, which also saves the agent from rediscovering (and paying tokens for) the same interaction logic in every app. The layout, fonts, charts and styling are plain HTML, CSS and whatever charting library you like, so a customisation that needed a Sisense plugin is now part of the prompt.

Inspect any number

Every anfra app has Inspect built in. Opening it on a chart walks a number back to its source in three steps: the metric definition in AMQL, the query on that page, and the exact SQL that ran on your warehouse. A reviewer can see which joins a number went through without reading the app's code, which is the question the Sisense model view made hardest to answer.

The whole BI project is files you own

An anfra project is a folder in Git:

my-project/
├── models/                  # tables and joins
├── datasets/                # metrics such as active accounts
├── apps/                    # your custom apps
└── .anfra/data_sources.yml  # warehouse connection (git-ignored)

Your coding agent reads the same files your team reviews, so a change to a metric goes through a pull request and every app picks it up on the next query. That gives you the version control and rollback Sisense never had.

How a Sisense stack maps to anfra

You also do not need to move everything at once. The pattern that works best for teams with a large Sisense estate is to leave the standard dashboards where they are while the switching cost is high, build every new app on anfra, and send exploratory questions to an agent connected over MCP. Sisense then shrinks to the dashboards nobody has rebuilt yet, and the next renewal covers far less.

What is open source today, and what is not

It is worth being precise here, especially for teams that bought Sisense to embed analytics for their own customers.

• Open source today (Apache 2.0): anfra Server, the SDK, the CLI, AMQL, the MCP server and the agent skills, which together give you semantic models, the query engine, the interaction patterns and Inspect. A project runs on your laptop or on one small VM, since the server is a thin Go binary.
• anfra Cloud (in beta, in the US region): logins and roles today, with SSO, row-level and viewer-level permissions, sharing links and audit logs on the way. Self-hosted anfra has none of these, so anyone who can reach the server can open its apps. Internal teams put it behind their own SSO proxy. Product teams embedding analytics for many customers need to handle authentication and tenant filtering in their own application layer until Cloud adds row-level permissions. A project you build on open-source anfra runs on Cloud unchanged.
• Planned: query caching, connecting external semantic layers such as dbt, Cube, Snowflake and Databricks, and evaluation and trust grading for agent answers. Until caching ships, every page load is a warehouse query, so pre-aggregated tables in the warehouse are the way to keep busy pages fast.

What it costs compared with Sisense

The anfra column has no per-seat line, no cube servers and no plugin licences, so adding a viewer or a page costs nothing beyond the warehouse queries it triggers. The real cost sits elsewhere: your team's time to model metrics properly and to stand up what Sisense bundled (logins, data security rules and scheduled reports) until anfra Cloud covers them. For a team that already runs a warehouse, that time goes mostly into metric definitions, which you should own anyway. For a team that needs multi-tenant embedded analytics with row-level rules in production this quarter and has no engineers to build authentication around it, a packaged embedded tool will still be less work for now.

So, can you replace Sisense with open source and AI agents?

For most data teams with a warehouse, yes, and the reason is that the part of Sisense that was expensive to replace has changed. The front end, including all the customisation that used to need plugins, now takes an agent an afternoon. What remains is the foundation (one definition per metric, joins you can read, a query engine that respects them, and a way to check any number), and that is the part anfra gives you in open source.

The quickest way to find out is to pick one Sisense dashboard your users open every week, define its metrics in an anfra dataset, and ask your coding agent to rebuild it against your own warehouse. After that, you can compare what you had to build yourself with what Sisense gave you. The quickstart (opens in a new tab) takes about ten minutes, the live demos (opens in a new tab) show what agents have built so far, and the source is on GitHub (opens in a new tab).

Sources

• How good is Sisense?, r/BusinessIntelligence (opens in a new tab) (October 2026)
• Sisense pricing, r/BusinessIntelligence (opens in a new tab) (October 2026)
• Sisense Pricing: what's your experience?, r/BusinessIntelligence (opens in a new tab) (October 2026)
• Best Sisense Alternatives for Embedded Analytics in 2026, Holistics blog (opens in a new tab) (October 2026)
• anfra documentation (opens in a new tab) (October 2026)