Dune

• Name: Dune
• URL: https://dune.com/
• Category: onchain data-platform company / query-and-API operator / warehouse-replication and data-engineering company
• Summary: Dune belongs in companies/, not only projects/, because the useful question is not just where can someone run SQL over crypto data? but which named operator curates decoded tables, controls query execution and API access, provisions Datashare into customer warehouses, manages uploads and materialized views, and decides how much of a team’s data pipeline gets built on Dune-specific surfaces? The practical leverage is not a novel protocol primitive. It is the company-run data and workflow shell that teams can start treating as their default source of onchain truth.
• What it does:
  • Operates a web-based SQL editor and dashboard environment for querying, visualizing, and sharing blockchain data across 100+ chains
  • Runs a Data API that lets customers execute queries, retrieve results, manage queries, upload custom datasets, create materialized views, coordinate pipelines, and monitor account usage programmatically
  • Provides Datashare so Dune’s processed blockchain tables can be replicated into customer Snowflake, BigQuery, Databricks, or dbt-connected environments, with Dune configuring sharing on its side
  • Publishes connectors and client tooling across Python, TypeScript, Go, Rust, CLI, and dbt-template repos, which makes Dune a real developer platform rather than only a dashboard website
  • Markets the stack for analytics, engineering, application development, and accounting / audit / AML workflows, not just public dashboards for researchers
• Key claims:
  • Dune docs describe the product as the onchain data platform for analytics, data engineering, and application development and say the company indexes 100+ blockchains, stores 3+ petabytes of data, and serves 1,500+ paying customers
  • The docs product surface explicitly spans Data Hub, Datashare, the Data API, dbt Connector, and BI-tool connectors, which is strong first-party evidence that Dune should be read as a company-run data platform rather than just a chart website
  • The Data API overview says customers can execute queries, manage data, coordinate pipelines, upload datasets, create materialized views, and track usage through authenticated REST endpoints
  • Datashare docs say Dune replicates its processed blockchain data directly into customer warehouses and that Dune configures sharing permissions on its side, which makes the operator boundary unusually explicit
  • The same Datashare docs emphasize privacy, enterprise contact flows, warehouse-specific setup requirements, and ongoing support, all of which reinforce that the sticky dependency is a named company and service workflow rather than a neutral data protocol
  • The public GitHub organization shows official API clients, a CLI, dbt templates, and supporting tooling, which makes the operator’s preferred integration paths visible and durable
• Whitepaper: No classic standalone Dune company whitepaper is the important artifact here. The useful primary materials are the Dune docs homepage, Data API overview, Datashare docs, and the public GitHub organization. The broader source bundle remains ../whitepapers/dune-primary-sources-2026-04-25.md.
• Sources:
  • https://docs.dune.com/
  • https://docs.dune.com/api-reference/api-overview
  • https://docs.dune.com/datashare/datashare
  • https://github.com/duneanalytics

Why this company note belongs in the corpus

• Dune is often discussed as if it were just the place analysts publish dashboards. Its own docs make the sharper point: Dune is trying to become the managed warehouse, query, API, replication, and pipeline layer that teams use to make blockchain data operational.
• That makes the entity boundary more useful than a generic project note. The durable question is who curates the decoded tables, provisions access, sets the API and replication surface, and becomes the place where downstream teams decide what their production data model should look like.
• Datashare is the clearest control-surface signal here. Once a team lets Dune replicate processed tables directly into its warehouse and starts building internal models on top, the dependency is no longer we looked at a dashboard; it is we outsourced a meaningful chunk of our blockchain data plumbing to one named operator.

Internal linkages

• Project-layer alias: dune.
• Closest adjacent data-platform reads: allium and coin-metrics.
• Methodology-and-listing contrast where public market legibility matters more than warehouse replication: defillama.
• Indexing-market contrast where data access is coordinated through a protocol layer rather than a company-run SaaS stack: the-graph.

Protocol / company boundary

• There is no especially useful standalone Dune protocol doing the main analytical work here.
• The meaningful surface is the company-run data platform: decoded-table curation, query execution, saved-query management, uploads, materialized views, pipelines, warehouse replication, and support-led enterprise setup.
• Even the apparently neutral parts of the stack, like table coverage or warehouse sync, are company-authored packaging decisions about schemas, freshness, supported connectors, and which workflows are first-class.
• That is why this note belongs in companies/: the sticky dependency is a named operator and service boundary, not a protocol primitive.

Control surface

• Practical leverage sits in which chains and decoded tables Dune supports, how schemas evolve, which query and pipeline features are exposed, how API credentials and usage are managed, and how much of a team’s internal analytics or compliance workflow gets built on Dune-managed objects.
• Datashare adds another important choke point: which warehouses are supported, how replication is configured, what refresh cadence is available, how customer identities and principals are onboarded, and when Dune-side support or provisioning becomes necessary to keep internal data flows healthy.
• The company also influences legibility by deciding what gets normalized into convenient shared tables versus what remains hard or bespoke. That sounds boring, but it strongly shapes which ecosystems, activities, and metrics are easiest for customers to operationalize.
• Read Dune as a company-run blockchain data control plane first, not as neutral public analytics infrastructure.

Failure-prevention lens

• Ask whether a team is using Dune as an exploratory analytics tool or as production data infrastructure for monitoring, accounting, AML, customer-facing features, or internal reporting.

• Ask what breaks if Dune changes schemas, refresh cadence, access rules, or product priorities: dashboards are easy to replace, but warehouse replication, saved queries, materialized views, and pipeline logic are much stickier.

• Ask which parts of the data model remain independently reproducible from raw chain data versus effectively inherited from Dune’s decoded tables and packaged abstractions.

• Ask whether downstream users are treating Dune outputs as convenient views or as authoritative truth for operational decisions. The more it becomes the latter, the more this company boundary matters.

• Last reviewed: 2026-08-08 UTC