Matomo and SensorFlow are both relevant when a team wants to run analytics on its own infrastructure. They are not substitutes for the same job. Matomo is a mature web analytics application with tracking, reports, dashboards, and a self-hosted edition. SensorFlow is a narrower path for teams that already send compatible Sensors Data SDK events and want those events in their own ClickHouse, queried through SQL and Apache Superset.
Short answer: Pick Matomo if you need a ready-to-use website analytics interface, visitor reports, campaigns, goals, and event tracking. Evaluate SensorFlow if your starting point is existing Sensors Data SDK instrumentation and your desired destination is ClickHouse. SensorFlow's demo stack can be run before purchase, but activating real SDK ingestion requires a SensorFlow license. Neither tool should be presented as a free, feature-equivalent replacement for the other.
This comparison uses public documentation as of September 2026. It is not a performance benchmark or a claim that one product is universally better.
What are you actually replacing?
The useful question is not merely whether both projects can be self-hosted. Ask where the boundary you need to change sits.
If your team currently looks at website acquisition, visits, content performance, campaigns, and conversion goals, the boundary is probably the analytics application. Matomo already provides that application, plus an official event-tracking workflow. Its on-premise installation guide says the self-hosted edition is free to download. The event-tracking guide describes the interaction data it can collect.
If your team already has Sensors Data SDK calls across web, mobile, or backend code, the boundary may instead be the event receiver. SensorFlow's documented flow is compatible SDK traffic → Go ingestion → ClickHouse → Superset. The objective is to test a server-side destination change without rewriting all instrumentation at once. See the SensorFlow repository and getting-started guide for the actual deployment and license steps.
That narrower scope matters. SensorFlow does not turn Superset into Matomo's visitor interface, and Matomo does not natively make an existing Sensors Data SDK send its events to ClickHouse. A team can build additional integrations, but that work belongs in the comparison.
Side-by-side: where each tool fits
| Decision | Matomo | SensorFlow |
|---|---|---|
| Primary job | Web analytics application with built-in reports and tracking | Server-side path from compatible Sensors Data SDK events to ClickHouse |
| Self-hosting | Official On-Premise edition | Docker-based stack and self-operated ingestion |
| Typical storage | MySQL or MariaDB for Matomo On-Premise | ClickHouse for event rows |
| Analysis interface | Matomo reports and dashboards | ClickHouse SQL and Apache Superset |
| Raw-data access | API export; on-premise users can also read the underlying database | Direct ClickHouse queries are the normal workflow |
| Existing Sensors Data SDK | A separate migration/integration exercise | The principal compatibility use case, subject to testing |
| Funnels | Check plan or on-premise plugin entitlement | Model in SQL and present in Superset; not a comparable no-code UI |
| Real ingestion terms | Depend on hosting, plan, and plugins | Demo before activation; real SDK ingestion requires a license |
Matomo's system requirements name PHP and MySQL/MariaDB for its on-premise application. This is an architectural difference, not evidence that one database is faster. Capacity, operational cost, and query performance must be measured on your workload.
Matomo is not just page views
It would be inaccurate to dismiss Matomo as a simple traffic counter. Its current feature page includes event tracking, ecommerce tracking, segmentation, dashboards, API access, and reporting features. Matomo's event-tracking documentation covers interactions such as clicks, videos, downloads, and forms. For many website teams, those built-in workflows are the reason to choose it: an analyst can navigate a product interface without first maintaining a catalog of SQL queries.
It would also be inaccurate to say that only SensorFlow provides access to raw data. Matomo documents both HTTP API export and direct read-only access to its MySQL database for on-premise installations. If your requirement is simply to extract your own events, Matomo On-Premise deserves a fair evaluation. The sharper distinction is where raw rows live by default and how the team expects to work with them. SensorFlow is designed around ClickHouse as the event store; Matomo's application and schema are designed around Matomo's reports.
Some advanced Matomo features depend on a plan or premium plugin. The current on-premise pricing page places Funnels in a paid bundle rather than the free Community feature set. Verify the current bundle, support terms, and deployment model on Matomo's pricing page before making a purchase decision.
SensorFlow is not a complete Matomo replacement
The SensorFlow README makes a two-stage distinction: the installer starts supporting services, demo events, and a Superset dashboard without a license; real Sensors Data SDK ingestion starts only after a license is installed and activation is run. Calling the entire production ingestion path free would hide a material requirement.
After activation, the attraction for a SQL-oriented team is that the event receiver writes to a ClickHouse database the team operates. Engineers can inspect event rows, verify property types, define metrics, and join with other data using their own SQL. Superset can present dashboards, but it does not automatically supply Matomo's reporting vocabulary or workflow. The team owns metric definitions, dashboard quality, retention, backup, security, and upgrades.
The compatibility claim must stay narrow. Working with compatible Sensors Data SDK traffic does not establish parity for every SDK generation, encrypted payload, visual tracking mode, identity rule, or plugin. A proof of concept should use the exact SDK versions and event payloads already deployed.
A concrete evaluation
Start with one business question: “Of the people who clicked sign-up this week, how many finished registration?” Run the same decision workflow in each candidate system.
- Inventory current instrumentation. Record event names, properties, user identifiers, SDK versions, and destinations. If the application uses Matomo's tracker rather than Sensors Data SDKs, SensorFlow's compatibility advantage may be irrelevant.
- Define the event contract. Specify whether “sign-up” means a click, submitted form, created account, or verified account. Neither product can fix an ambiguous definition.
- Deploy in non-production. Follow Matomo's installation guide and SensorFlow's getting-started guide. Keep test tokens, database credentials, and network ports private.
- Send identifiable test events. Include a unique test user and non-sensitive properties. Confirm both the HTTP response and the stored record or report; an accepted request alone does not prove retention.
- Reconcile counts and identities. Compare event counts by day, environment, and event name. Check anonymous-to-authenticated transitions and time zones. Treat divergence as a finding, not a rounding error.
- Let intended users answer the question. Ask a marketer or product manager to find the answer in Matomo, and ask the intended SQL/Superset owner to produce and explain the query. The working experience matters.
- Test failure and recovery. Stop the database in a test environment, rotate a token, restore from backup, and see whether lost or delayed events can be diagnosed before production use.
A small demo verifies a path; it does not predict production throughput or total cost. Measure representative volume, query mix, retention, and operations effort before selecting a winner.
When should you choose each?
Matomo is the more direct choice for a website team that wants a complete analytics interface now. Reports, goals, campaigns, and event tracking already live in the same application. Its on-premise option allows self-hosting, and the free Community tier may cover the required core features. Teams can later evaluate paid plugins and support.
SensorFlow is worth a proof of concept when compatible Sensors Data SDK events already exist, ClickHouse is the desired event store, and the team can operate SQL and infrastructure. The first milestone is to start the demo, inspect sample events, activate licensed ingestion if the real path is needed, then send one event from the actual SDK and query it back. Expand gradually only after identity and property types check out.
Matomo should not be characterized as lacking events or raw-data access. SensorFlow should not be characterized as a complete or freely activated Matomo replacement. Choose based on the boundary you need to change and on who will operate and use the system.
SensorFlow is an independent project. It is not affiliated with, endorsed by, or certified by Matomo or Sensors Data.
Top comments (0)