The latest articles on DEV Community by SensorFlow (@sensorflow). https://dev.to/sensorflow https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4123045%2Fd2cb1876-ab98-454b-b579-f51a9afe52b4.png https://dev.to/sensorflow en SensorFlow Mon, 14 Sep 2026 07:09:09 +0000 https://dev.to/sensorflow/moving-product-analytics-safely-start-with-the-ingestion-boundary-33mp https://dev.to/sensorflow/moving-product-analytics-safely-start-with-the-ingestion-boundary-33mp <p>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.</p> <p>SensorFlow is an open-source, self-hosted stack designed for a narrow, inspectable transition:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>SDK event upload → Go ingestion service → ClickHouse → Apache Superset </code></pre> </div> <p>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.</p> <h2> What the stack makes visible </h2> <p>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.</p> <p>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.</p> <h2> The operational boundary still matters </h2> <p>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.</p> <p>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.</p> <h2> Evaluate the ingestion boundary </h2> <ul> <li><a href="https://github.com/data-analyze-bi/sensorFlow" rel="noopener noreferrer">Open-source repository</a></li> <li><a href="https://sensorflow.site/docs" rel="noopener noreferrer">Documentation</a></li> <li><a href="https://superset.sensorflow.site/" rel="noopener noreferrer">Read-only Superset demo</a></li> </ul> <p>I’m one of the maintainers. Feedback on ingestion compatibility, ClickHouse schema choices, deployment reliability, and production validation would be especially useful.</p> opensource dataengineering SensorFlow Sun, 13 Sep 2026 17:45:46 +0000 https://dev.to/sensorflow/we-moved-the-analytics-backend-first-building-sensorflow-with-go-clickhouse-and-superset-2l68 https://dev.to/sensorflow/we-moved-the-analytics-backend-first-building-sensorflow-with-go-clickhouse-and-superset-2l68