Evidence: product and architecture
Evidence is a strong choice for teams that want business intelligence to live in the same disciplined workflow as analytics code, rather than in a drag-and-drop dashboard editor. This Evidence review finds that it is best for data teams comfortable with SQL, markdown, version control, and review-based development; teams that need non-technical users to build ad hoc dashboards independently should look elsewhere. Its core proposition is clear: build polished, interactive data products using SQL and markdown, then publish them internally, share them with customers, or embed them in an application.
Overview
Evidence positions itself as an open-source, code-based alternative to conventional drag-and-drop BI tools. Instead of configuring charts through a visual canvas, analysts write SQL queries and markdown documents, then combine them with interactive visualization components. That model makes the tool particularly relevant for analytics engineers and data engineers who already treat transformations, metrics definitions, and documentation as versioned assets.
The decision is not subtle: Evidence favors repeatability and engineering control over visual self-service. We recommend Evidence for teams that want reports and dashboards to go through pull requests, testing, and version control alongside the rest of their data work. The trade-off is that a code-first interface creates a higher entry bar for business users who do not write SQL or work in repositories.
Evidence also extends beyond internal reporting. Its product description includes dashboards, articles, data apps, AI chat, customer analytics, embedded analytics, and business reviews. That breadth matters because the same SQL-and-markdown approach can support a polished internal executive report or a customer-facing embedded experience, but it also means a team must establish its own conventions for report structure, permissions, deployment, and ownership.
Public repository activity supports the view that Evidence is an active open-source project, though it is not proof of enterprise adoption. The GitHub repository has 6,847 stars, uses JavaScript as its primary language, carries an MIT license, and was last pushed on February 18, 2026. Its latest listed release is @evidence-dev/evidence@40.1.8, dated February 6, 2026, which is a useful concrete signal for teams evaluating project maintenance.
Key Features and Architecture
Evidence’s architecture centers on authored files rather than a dashboard-building canvas. Authors write readable SQL to retrieve data and markdown to compose narrative, headings, and presentation, then add interactive visualization components to turn the result into a responsive data product. This is a practical fit for teams that already use software-development practices for dbt projects, analytics repositories, or metric documentation.
Key capabilities include:
- SQL and markdown authoring: Evidence lets teams build reports directly from SQL and markdown. This creates a durable audit trail for query logic and explanatory context, but it requires authors to be competent with both data querying and document-oriented composition.
- Publication-quality visualization design: The product emphasizes visualizations designed for all device sizes. That supports polished stakeholder and customer-facing outputs, although the supplied product data does not establish how much chart-level configuration can be done without editing authored source.
- Responsive interactive data products: Teams can combine data-visualization components into dashboards and data apps, then publish, share, or embed the result. This is more flexible than treating every output as a static report, but it broadens the engineering responsibility around release management.
- Real-time syntax validation: Evidence automatically validates SQL, markdown, and component syntax while authors work. Catching errors before a report reaches review is valuable, especially when one document contains query logic, prose, and visualization syntax.
- Intelligent autocomplete: The development environment provides suggestions for components, visualization options, SQL queries, and related inputs. This reduces friction in a text-based workflow, though it does not remove the need to understand the underlying data model.
- Version control and testing: Evidence explicitly supports tracking changes and testing reports with the same tools software engineers use. This is one of its strongest differentiators for regulated, high-stakes, or frequently changed reporting, because a dashboard change can be reviewed as a change to source.
- AI-enhanced development: Its AI agent can look up documentation, check a schema, debug errors, and write Evidence markdown. That can accelerate experienced authors, but teams should still review generated SQL and narrative output before publishing.
- Performance-oriented query layer: Evidence describes sub-second interactions on millions of records and queries of billions of rows in milliseconds through columnar storage and vectorized execution. It also describes multi-level caching, automatic query optimization, and memory management; these are meaningful technical claims, but the supplied data provides no benchmark methodology or workload definition.
The project’s repository topics include analytics, business intelligence, dashboards, data engineering, data science, data visualization, dbt, and DuckDB. Those labels reinforce that Evidence belongs in an engineering-led analytics stack rather than a purely business-led reporting environment. The repository description summarizes the architecture accurately: business intelligence as code for fast, interactive visualizations in SQL and markdown.
Ideal Use Cases
Evidence is most effective when the report itself should be treated as a maintainable software artifact. A data platform team of five to fifteen people supporting a growing analytics organization can use it to put recurring operating reports, KPI explanations, and dashboard changes through the same repository workflow as transformation code. In that setting, SQL and markdown are not obstacles; they are the shared language that makes logic inspectable and changes reviewable.
A second strong scenario is customer-facing or embedded analytics. A B2B software team that needs to publish responsive dashboards or data applications can use Evidence’s interactive components and embedding-oriented product positioning to create a controlled presentation layer. The trade-off is that the team is building and maintaining a data product, not simply handing a business user a dashboard editor, so ownership should sit with an engineering-capable analytics function.
A third use case is analytical reporting where narrative matters as much as a chart. For example, a data leader can standardize monthly business reviews as markdown-based documents that include SQL-backed visualizations, written interpretation, and a versioned history of edits. This is especially useful when stakeholders need a consistent explanation of what changed, rather than a collection of unannotated dashboard tiles.
Evidence is also appropriate for data teams that want automated reports without separating the query definition from the final presentation. Its real-time syntax validation and autocomplete help authors work faster, while version control and testing make it easier to govern changes across multiple reports. We recommend it for organizations where analytics engineers already own the semantic and presentation layer, or where analysts are expected to work comfortably in code.
Do not use Evidence if your primary requirement is broad, no-code dashboard self-service for a large population of business users. The provided product information establishes SQL and markdown as the authoring model, so forcing non-technical users into that workflow will turn a governance advantage into a bottleneck. Avoid it as the sole BI interface if your operating model depends on casual users assembling their own reports without repository access, code review, or SQL fluency.
Strengths & Trade-offs
In our evaluation, Evidence’s strengths are concrete and closely tied to its code-first design:
- Source-controlled reporting is built into the product model. SQL, markdown, report changes, and tests can use the same version-control practices as engineering work, making logic reviewable rather than hidden inside a visual editor.
- It supports narrative-driven analytics. Markdown lets a team pair explanations with interactive visualizations, which is better suited to recurring business reviews and decision documents than dashboards that provide no written context.
- The development experience includes guardrails. Real-time validation covers SQL, markdown, and component syntax, while autocomplete covers components, visualization options, and SQL queries; this directly reduces authoring mistakes in a multi-language document.
- Performance claims target substantial analytical workloads. Evidence states sub-second interaction on millions of records and milliseconds-scale queries across billions of rows using columnar storage and vectorized execution.
- The project is inspectable and actively maintained. It is MIT-licensed, has 6,847 GitHub stars, and lists a February 2026 release, which are public signals that teams can examine when assessing ecosystem health.
- It is designed for more than internal dashboards. The documented ability to publish internally, share with customers, or embed outputs makes Evidence relevant to product analytics and customer analytics use cases.
Its limitations are equally important:
- Evidence is weak for no-code self-service. Its central workflow requires SQL and markdown, so non-technical users cannot be assumed to build or modify reports comfortably without support from a data team.
- The flat price is high for a small team. At $2,500 per month for unlimited users, Evidence is priced for an organisation rather than a handful of analysts, and Enterprise carries no published figure at all.
- The supplied performance claims lack benchmark detail. “Millions of records,” “billions of rows,” and “milliseconds” are useful directionally, but the available material does not define hardware, datasets, concurrency, or query shapes.
- AI assistance still requires expert review. An agent that checks schemas, debugs errors, and writes markdown can speed drafting, but it does not eliminate responsibility for validating SQL logic, business definitions, and published conclusions.
