Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Umami and SensorFlow solve different starting problems. Umami is a ready-made web and product analytics application: you add a site, install its tracking script, and read reports in its interface. SensorFlow is a self-hosted event pipeline: it receives events from compatible Sensors Data SDKs, stores them in ClickHouse, and lets your team query them with SQL and build dashboards in Apache Superset.
If you want website traffic and conversion reporting that works without building anything, start with Umami. If your engineers already instrument products with Sensors Data SDKs and want the raw events in a ClickHouse database that you run, SensorFlow is the one to evaluate. The rest of this article explains why, and what each choice asks of your team.
How the two products compare
| Decision point | Umami | SensorFlow |
|---|---|---|
| Starting job | Website and product analytics with a tracking script and a reporting interface | Routing compatible Sensors Data SDK events into infrastructure your team operates |
| Collection | Umami tracker, plus documented event and API workflows | Sensors Data SDKs pointed at SensorFlow’s collector; SDK and event semantics must be validated for your versions |
| Storage and analysis | Umami’s own application, on Umami Cloud or self-hosted | ClickHouse storage, SQL queries, and Apache Superset dashboards |
| Hosting responsibility | Umami Cloud is managed; self-hosting means running the documented Node.js and PostgreSQL stack | Your team operates ingestion, ClickHouse, Superset, access control, backups, scaling, and upgrades |
| Best fit | Site owners and product teams who want built-in reports | Engineering or data teams with existing compatible SDK instrumentation and a need for ClickHouse event data they own |
| Check before choosing | Current feature and plan details, and whether you need managed or self-hosted | Production license terms, SDK compatibility, identity and timestamp handling, capacity, and operating readiness |
These comparisons follow the products’ documentation. No measured performance comparison exists in the sources reviewed for this article. The most detailed side-by-side material comes from SensorFlow itself, in a vendor-authored comparison on dev.to, which states that it is not a benchmark. Treat it as a statement of intended positioning rather than independent evidence.
Free tools Windows power users keep installed
One-click scans. No signup required.
Umami: an application for web and product analytics
Umami’s documentation describes version 3 as an open-source web and product analytics platform. Its feature set covers the reporting most site owners look for first, and extends into product analysis:
#1 Best Overall
- Acquisition reporting: pageviews, visitors, referrers, locations, devices, and campaigns
- Custom events and behavior analysis
- Goals, funnels, attribution, and retention
- Revenue reporting
- Dashboards, teams, and sharing
- API integrations
On privacy, Umami’s introduction says its collection avoids cookies, cross-site tracking, and automatic collection of personal data. Any information your site deliberately sends remains your responsibility as the operator.
Hosting options
Umami is available as managed Umami Cloud or as a self-hosted installation. The project repository documents a source setup based on Node.js and PostgreSQL, along with Docker installation. Check the version-specific documentation before you rely on any implementation detail, because setup steps change between releases.
API access
Umami exposes an API for both self-hosted and cloud installations. Cloud API use requires an API key. The Umami API documentation covers the endpoints and authentication.
SensorFlow: an event pipeline for Sensors Data SDKs
SensorFlow’s quick start describes a single data path: official Sensors Data SDKs send events to SensorFlow, which stores them in ClickHouse, where they are analyzed with SQL and Apache Superset. The value SensorFlow claims is that event detail stays on infrastructure you manage, and that analysis happens through tools you already know. The quick start walks through validation in three steps:
- Send an event from an official Sensors Data SDK.
- Confirm the stored row in ClickHouse.
- Run a query against that data in Superset.
SDK protocol compatibility does not mean the third-party SDK vendor endorses SensorFlow. The guide advises testing the specific SDK versions and extensions you use.
Licensing and what the free demo covers
SensorFlow’s documentation provides a local demo that runs without a license. Production ingestion of real SDK payloads requires a separate SensorFlow license. The project homepage describes the software as Apache-2.0 and self-hosted, but public source availability does not mean every production deployment is license-free. Pricing and promotions appear on the SensorFlow homepage and change over time, so confirm them there before budgeting. The homepage also shows event and performance counters; these are illustrative and are not customer results.
Operating load and hardware
SensorFlow’s quick start gives the following starting hardware figures. They are vendor recommendations in current quick-start documentation, not independent benchmarks or guarantees.
| Tier | CPU | Memory | Storage |
|---|---|---|---|
| Minimum test setup | 4 cores | 8 GB | 100 GB SSD |
| Production starting point | 8 cores | 16 GB | 500 GB SSD |
Actual requirements depend on event volume, retention period, query load, and architecture. The quick start does not specify a storage model, interface, or endurance rating, so choose SSD hardware against your own capacity and write workload.
Best Value
What self-hosting transfers to your team
SensorFlow’s architecture guidance names reliability, security, scaling, backups, and upgrades as responsibilities that move to the operator. The same guidance points out that self-hosting alone does not prove that no data leaves your network, and does not establish compliance. Every dependency and integration needs its own review.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Which one fits your setup
- Choose Umami if your main job is understanding website traffic and conversions through a prepared analytics interface, and either managed hosting or a self-hosted Umami installation fits your team.
- Evaluate SensorFlow if your team already uses Sensors Data SDKs, wants event details stored in a ClickHouse database it controls, and has capacity to operate the collection, database, and BI layers.
- Do not choose SensorFlow for ClickHouse alone if your team lacks operational capacity or needs a turnkey analytics application. Confirm the full workflow and every report you need before committing.
Checks before a SensorFlow migration
A successful HTTP response from the collector does not prove that an event was stored correctly or that it means the same thing as before. Work through these checks with the exact SDK versions in production:
Quick Recap
- List representative anonymous, logged-in, and business events, and pin the SDK versions you will test.
- Send each event and confirm that it is stored as a ClickHouse row, not only that the request succeeded.
- Check identity joins, timestamps, and property types against your current reporting.
- Test retries and duplicate submissions, and confirm how repeated events are counted.
- Rebuild your key dashboards in Superset and compare the results with your current numbers.
- Verify backups and write down a rollback path before you switch production traffic.
|bottom_line_html
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
