Replacing an analytics system is rarely a dashboard decision. The risky part is the event-ingestion boundary: web, Android, iOS, mini-program, and backend clients often emit events on different release cycles, with years of naming conventions and identity edge cases.
SensorFlow is an open-source, self-hosted stack designed for a narrow, inspectable transition:
SDK event upload ā Go ingestion service ā ClickHouse ā Apache Superset
For teams already using the standard upload flow of official Sensors Data SDKs, the practical question becomes whether ingestion and storage can move into infrastructure they control without rewriting every client integration at once.
What the stack makes visible
SensorFlow processes incoming events in Go, stores them in ClickHouse, and makes them available to Apache Superset. That gives operators a direct path to inspect raw records, define metrics in SQL, and build dashboards against their own database.
The point is not to hide analytics behind another hosted layer. It is to make event data operate like the rest of the data stack: reviewable schema changes, inspectable queries, and access controls that fit existing infrastructure.
The operational boundary still matters
Self-hosting is not a shortcut around operations. Docker Compose is appropriate for evaluation, while production requires HTTPS, unique credentials, access controls, monitoring, backups, restore tests, and capacity planning.
SensorFlow also has deliberate scope limits. It is not a feature-for-feature replacement for broad product-analytics suites: session replay, experiments, feature flags, and broad no-code workflows are not provided today. It is intended for engineering teams with existing multi-platform instrumentation, a need for data ownership, and the willingness to operate ClickHouse.
Evaluate the ingestion boundary
Iām one of the maintainers. Feedback on ingestion compatibility, ClickHouse schema choices, deployment reliability, and production validation would be especially useful.
Top comments (0)