Composable Analytics: The 2026 Build-vs-Buy Decision

Composable analytics means treating your data stack as discrete, swappable layers (storage, transformation, a semantic layer, and presentation) rather than one monolithic platform. The smart 2026 build-vs-buy decision is to buy the commodity layers and keep the differentiating ones, especially the BI and semantic layers, open and defined in code so you are never trapped behind someone else's roadmap.

For most of the last decade, "buying BI" meant buying everything at once: the storage, the modeling, the metrics, the charts, and the viewer, all bolted together inside one vendor's walls. That bundle was convenient right up until it was not. The moment your warehouse outgrew the tool, or your metrics needed to live somewhere a dashboard could not reach, the seams showed. The modern data stack has spent the last few years pulling those seams apart on purpose. This is the unbundling, and it changes what "build vs buy" even means.

The unbundled analytics stack

Composable analytics starts from a simple observation: the work of turning raw data into a decision is not one job, it is four.

• Storage and compute. Where the data physically lives and where queries run. Snowflake, BigQuery, Databricks, DuckDB, Postgres. This is the foundation, and it has become a genuine commodity. The query engines are fast, cheap, and broadly interchangeable for most workloads.
• Transformation. Where raw tables become clean, tested, documented models. This layer is now overwhelmingly owned by dbt™, which made SQL transformation a versioned, reviewable, testable software practice.
• Semantic layer. Where business logic lives: what "revenue" means, how "active customer" is defined, which tables join to which and on what keys. This is the layer that decides whether two dashboards agree on a number.
• Presentation. Where humans actually see the data: dashboards, charts, exploration, embedded views, and increasingly, answers generated by AI.

Each of these is now its own market with its own best-in-class tools, connected by open interfaces instead of proprietary handoffs. That is the whole idea of a modern data stack: pick the best tool for each layer and wire them together, rather than accepting one vendor's opinion on all four.

The unbundling is not just architectural neatness. It is a hedge. When any single layer is swappable, no single vendor can hold your analytics hostage.

What composability actually buys you

Composability is not free. Wiring four layers together is more work up front than clicking "deploy" on an all-in-one platform. So it has to buy you something real. It buys three things.

Optionality. You can replace any one layer without rebuilding the rest. Migrating warehouses should not mean rebuilding every dashboard. Switching your presentation layer should not mean re-deriving every metric. In a composable stack, a migration touches one layer and leaves the contracts at its edges intact.

Best-of-breed, not lowest-common-denominator. Bundled suites optimize for "good enough at everything." That means the charting is mediocre because the vendor spent their quarter on connectors, or the modeling is thin because they spent it on charts. When you compose, each layer is chosen by the team that cares most about it, and you stop paying the bundle tax of features you will never use.

Leverage on price and roadmap. A monolith renews on its own terms. A composable stack renews layer by layer, which means each vendor competes against a real, credible alternative. The leverage is structural, not negotiated.

The cost, to be honest, is integration and ownership. Someone has to own the contracts between layers. That cost is exactly why the build-vs-buy line matters.

Where to draw your build-vs-buy line

The mistake teams make is treating build-vs-buy as one decision. It is four, one per layer, and the right answer is usually different for each.

Here is the heuristic I trust: buy the commodity layers, control the differentiating ones.

• Storage and compute: buy. This is the clearest "buy" in the stack. No competitive advantage comes from running your own query engine. Pick a managed warehouse and move on.
• Transformation: buy the tool, own the logic. You buy dbt™ (or its runner), but the models, the tests, and the documentation are yours, in your repo, in version control. The tool is bought; the asset is built and owned.
• Semantic layer: own it in code. This is where your business actually lives. The definition of revenue, the join paths, the grain of every metric. If this is locked inside a vendor's proprietary format, you have handed away the most valuable thing in your stack. Own it as code.
• Presentation: buy openness, not lock-in. You should not build a charting library from scratch. But the BI layer you buy must read your owned semantic layer and live in your repo, not trap your dashboards in a format only it can open.

The pattern across all four: build and own the things that encode your business; buy the things that are pure infrastructure. A query engine is infrastructure. The definition of your North Star metric is not.

Avoiding lock-in at the BI layer

The BI layer is where lock-in is most expensive and most common, because it is the layer business users touch every day. Dashboards accumulate. Once a few hundred reports live inside a proprietary tool, the switching cost is enormous, and the vendor knows it.

Lock-in at this layer has a few tells. Watch for them:

• Dashboards you cannot read without the tool. If your reports live only in a proprietary binary format or a vendor's cloud, you do not own them in any meaningful sense. You are renting access to your own work.
• Logic that cannot leave. When metric definitions, filters, and joins are trapped in the BI tool's UI, every other consumer (notebooks, alerts, AI agents, reverse ETL) has to re-derive them. That is how metrics drift and how the same KPI ends up with three different values.
• No diff, no review, no history. If you cannot see what changed in a dashboard, who changed it, and roll it back, you do not have a versioned asset. You have a liability.

The antidote is to require that your presentation layer store its definitions as plain text in your own repository. Plain text means Git. Git means diffs, pull requests, code review, history, and CI. The dashboard becomes a versioned artifact you own, not a record inside someone else's database. This is the heart of the BI-as-code approach, and it is the single best insurance policy against BI lock-in.

The glue is the semantic layer

Composability has a quiet failure mode: four layers that work individually but disagree at the edges. The storage team's notion of a "session" does not match the dashboard's. The reverse ETL job computes revenue one way and the executive dashboard another. Each layer is best-of-breed, and the numbers still do not tie out.

The semantic layer is the glue that prevents this. It is the one place where "revenue," "active user," and "churn" are defined once, with their join paths and their grain, and every consumer reads from it. The warehouse, the dashboards, the embedded views, the alerts, and the AI agents all resolve the same definition to the same SQL.

That is why the semantic layer is the part of a composable stack you most want to own in code. It is the interoperability contract. When metrics, dimensions, and relations are defined as version-controlled text, swapping any other layer is safe, because the meaning of the data travels with the definitions, not with the tool. We have written more about why the semantic layer is what makes analytics AI-ready: an agent is only as trustworthy as the definitions it queries, and those definitions belong in code, not in a UI.

A composable stack without a shared semantic layer is just four tools in a trench coat. With one, it is a coherent system.

Visivo as the composable BI layer

Visivo is built to be the open, code-first BI and presentation layer in exactly this kind of stack. It does not try to be your warehouse, your transformation tool, or your ingestion pipeline. It plugs onto the warehouse you already run and the dbt™ models you already maintain, and it is the layer where your semantic definitions and dashboards live as code.

In practice that means:

• Your dashboards are plain-text YAML in your repo. Models, metrics, dimensions, relations, and insights are defined as code, reviewed in pull requests, and versioned in Git. There is no proprietary binary, no UI-only state, nothing you cannot read without us.
• The semantic layer is yours. Metrics and dimensions are defined once and resolved consistently for every consumer, so a number means the same thing on a dashboard, in an embedded view, and to an AI agent.
• It composes, it does not capture. Because everything is code, swapping warehouses or evolving your dbt™ project does not require rebuilding your BI. The contracts at the edges hold.

You can see the shape of it in the examples gallery, or stand up the BI layer on your own warehouse in a few minutes via get started. The bet is simple: buy the infrastructure, own the meaning, and keep the layer your business looks at every day open and in code.

Previously in Visivo

In the last installment, Visivo v1.0.80: Lineage, Layout, and a Faster Local Loop, we walked through the release that tightened the local development experience ahead of 2.0. This post zooms back out to the architectural picture those releases fit into: a composable stack where Visivo is the open BI layer you own in code.