Both Plausible and SensorFlow can put analytics data on infrastructure you operate. Both involve ClickHouse. That is where the easy equivalence ends. Plausible is a privacy-first web analytics product with a tracking script, goals, and a purpose-built dashboard. SensorFlow is a narrower ingestion route for compatible, already-deployed Sensors Data SDK events: SDK → Go receiver → your ClickHouse → Apache Superset.
Short answer: If your problem is “I need readable website traffic and conversion reports,” start with Plausible. If your problem is “I already have Sensors Data SDK instrumentation and need to test landing its events in my own ClickHouse,” evaluate SensorFlow. Do not choose SensorFlow because someone says Plausible cannot self-host or cannot access raw ClickHouse data: Plausible's own repository documents both. And do not assume SensorFlow's open-source demo means production SDK ingestion is free: its getting-started guide separates demo deployment from licensed activation.
This comparison is based on vendor documentation available in September 2026. It contains no speed, cost, or privacy-compliance benchmark.
The first distinction is the event contract
Plausible's official Events API accepts POST /api/event with fields including domain, name, and url. Its JavaScript tracker can collect pageviews and custom events, and custom properties give those events context. That is a useful model for website teams. The dashboard organizes traffic sources, pages, goals, and conversions without asking an analyst to write SQL.
SensorFlow's documented starting point is different: existing Sensors Data SDK calls. It attempts to receive compatible SDK payloads through a Go service and write resulting events into ClickHouse. Its core value is preserving a tested subset of existing instrumentation while changing the server-side destination. That does not make its receiver a drop-in Plausible Events API endpoint. Nor does Plausible's Events API mean it automatically understands a Sensors Data SDK payload. A migration between the two needs an explicit payload mapping, identity decision, and verification of timestamps and properties.
Consider a practical example: a product already has mobile and web SDK calls for SignupStarted and SignupCompleted, including a stable account identifier. If the team wants the original events for joins and custom SQL, it should test the SensorFlow path with its exact SDK version. If a marketing team chiefly needs privacy-oriented website acquisition and goal reports, it may be faster to instrument Plausible's tracker and use its interface. The event contract, not the word “open source,” decides the implementation work.
Plausible also uses ClickHouse
It would be misleading to frame this as “Plausible's closed database versus SensorFlow's ClickHouse.” Plausible's repository states that its self-hosted Community Edition uses ClickHouse for analytics and PostgreSQL for other application data. It also explicitly says self-hosting allows direct access to raw data in ClickHouse. Its Community Edition deployment repository provides a Docker Compose route.
The more useful contrast is data model and default workflow. Plausible's ClickHouse supports Plausible's web analytics product; users normally work in its dashboard and API. SensorFlow's target is a team-operated event store whose rows are queried with ClickHouse SQL and visualized in Superset. If your organization wants to own metric definitions and join events to other warehouse data, that SQL-first approach may suit it. If the organization wants a finished, simple reporting interface, operating ClickHouse alone does not provide one.
| Decision | Plausible | SensorFlow |
|---|---|---|
| Primary task | Website and conversion analytics | Compatible Sensors Data SDK event ingestion into ClickHouse |
| Cloud option | Managed Plausible Cloud | Self-hosted project; check current commercial license terms for ingestion |
| Self-host option | Plausible Community Edition | Docker-based demo and licensed real-ingestion path |
| Analytics store | ClickHouse in self-hosted CE; PostgreSQL for application data | Team-operated ClickHouse |
| Default interface | Plausible dashboard, goals, reports, APIs | ClickHouse SQL and Apache Superset |
| Existing Sensors Data SDK | Requires integration or mapping to Plausible's event model | The principal compatibility use case, subject to testing |
| Built-in funnel UI | Available in eligible managed plans, not Plausible CE | No equivalent built-in no-code UI; model it in SQL/Superset |
| Raw-data access | Plausible CE allows direct ClickHouse access; Cloud has export/API options | Direct ClickHouse queries are the normal workflow |
The Plausible README distinguishes Cloud from CE. In particular, it lists marketing funnels, ecommerce revenue goals, SSO, and Sites API among premium features absent from CE. Its funnel documentation labels the feature as a Business-plan feature. This edition boundary matters, but it is not a claim that SensorFlow has a better ready-made funnel: it does not.
Privacy is not a one-word score
Plausible's product is intentionally privacy-first and designed around cookie-free website measurement. Its repository describes how it avoids storing personal data and persistent visitor identifiers. The Events API documentation adds an operational nuance: User-Agent and client IP information are used to derive unique visitor counts, and a misconfigured server-side X-Forwarded-For can silently drop an event even if the API returns HTTP 202. A production implementation should follow Plausible's exact guidance rather than equate “202” with a verified stored event.
SensorFlow can retain event identifiers and properties sent by an existing SDK in a ClickHouse database operated by the customer. That can enable deeper event-level analysis, but it also puts more privacy, consent, access-control, retention, and deletion responsibility on the operator. It would be wrong to market that as inherently more privacy-preserving than Plausible. The two systems are deliberately optimizing different analytics models.
The license and operations boundary
Plausible CE is AGPL-licensed and self-hostable without a Plausible subscription, while Plausible Cloud is a paid managed service. CE operators still pay for compute, storage, backups, maintenance, and incident response. Cloud includes a managed product and features based on the chosen plan.
SensorFlow's README documents an install-first workflow: supporting services and sample dashboards can run before a license is purchased, but receiving real Sensors Data SDK traffic requires a license and activation. This is a material difference from saying “clone the repository and all production ingestion works for free.” Evaluate the license alongside infrastructure and engineering costs.
Do not confuse running a demo with a production validation. For SensorFlow, inspect the sample events, then activate an appropriate license and send a real event from the SDK version you actually use. For Plausible, verify the chosen deployment edition, track an event with its documented API or tracker, create the required goal, and confirm that it appears in the dashboard. For both, test proxies, bot filtering, retries, backups, and access to the stored data.
A fair proof of concept
Choose one concrete question such as “How many visitors reach signup, and what properties distinguish the people who complete it?” Then:
- Write down the source events and identities. Website sessions and authenticated product users are not interchangeable units.
- Track the same business outcome in both tools. In Plausible, use its documented custom event and goal configuration. In SensorFlow, send a compatible SDK event and query the resulting ClickHouse row.
- Check actual data arrival. Inspect Plausible's dropped-event header where relevant, and query ClickHouse directly for SensorFlow. Do not stop at an HTTP success response.
- Ask the intended users to answer the question. A marketer may prefer Plausible's ready-made dashboard; a data engineer may prefer raw rows and SQL. Neither preference is universal.
- Record setup and maintenance work, product entitlements, and the cost of changing existing SDK code. Do not compare a managed Plausible Cloud plan against an unoperated SensorFlow demo as though they provide the same service.
Which should you choose?
Use Plausible when you want privacy-first website analytics with a focused dashboard and tracker. Its Community Edition is a real self-hosted option with ClickHouse and raw-data access, although the CE feature set differs from paid Cloud plans.
Test SensorFlow when you already have compatible Sensors Data SDK instrumentation, explicitly want that event stream in your own ClickHouse, and have the engineering capacity to define and operate the analyses. Its narrower scope and licensed real-ingestion boundary should be stated upfront. If you need a mature out-of-the-box website analytics application, Plausible is usually the better starting point.
SensorFlow is an independent project. It is not affiliated with, endorsed by, or certified by Plausible or Sensors Data.
Top comments (0)