Umami Alternative: Same Simplicity, More Depth

The short version

Umami is a lightweight, MIT-licensed, privacy-first analytics tool that runs on Postgres or MySQL. It is genuinely pleasant: easy to deploy, clean dashboard, no cookies, no bloat. Of all the tools in this space it is the closest to InsightsTrack in philosophy.

The reason to look elsewhere is usually depth. Umami answers "how much traffic, from where, to which pages" very well, and stops there by design.

Where Umami is genuinely better

• Deployment simplicity. One Node app plus one database. Marginally simpler than this stack.
• Maturity and adoption. Larger community and longer track record.
• Script size. Umami's tracker is roughly 2 KB; InsightsTrack's is ~9 KB gzipped, because it also captures heatmap, scroll, Web Vitals, and error data. Umami is the lighter script by a clear margin.
• Multi-tenancy. Well-established patterns for running many sites.

Both tools are MIT, both are cookieless, both are self-hosted. This is a close comparison, not a lopsided one.

Where InsightsTrack goes further

Behavioural data, not just traffic counts

Umami reports what happened. InsightsTrack also reports how it happened:

• Click heatmaps with rage-click and dead-click detection
• Scroll depth per page
• Core Web Vitals at p75 against Google's thresholds
• JS error tracking
• Multi-step funnels with per-step drop-off

If you have ever looked at a high bounce rate in Umami and wanted to know why, that gap is the difference. Reading heatmaps covers what that data actually tells you.

Read performance as data grows

Umami queries the same row-store database it writes to — Postgres or MySQL. That is simple and correct, and it means dashboard aggregations get slower as the events table grows, because answering "unique visitors per day over 90 days" walks a lot of rows.

InsightsTrack splits the workloads: PostgreSQL takes writes, a background sync feeds DuckDB, and every dashboard read hits the columnar engine. More moving parts in the design; considerably better read behaviour as the table grows. See the architecture and the sync engine.

SQL access

Umami has a clean API but no built-in query surface. InsightsTrack ships a read-only SQL editor over DuckDB, so you can answer questions the UI does not have a screen for — see 12 SQL queries every dashboard needs.

What each one costs to run

Both are modest, but they are not identical. Umami is one Node process and one database. InsightsTrack is a Node API, Postgres, and a DuckDB file on a volume — the DuckDB part is embedded, so it is a file rather than a service, but the API process needs enough memory to hold query working sets.

The DuckDB file is a derived cache, not a source of truth — every event lives in Postgres first. If the file is lost, the sync rebuilds it. That means your backup story stays "back up Postgres," same as Umami.

Data ownership and export

Both tools keep data on your infrastructure, so neither locks you in. The practical difference is how you get data out.

Umami exposes a documented REST API and you can always query its Postgres/MySQL tables directly with standard SQL — a genuine advantage of storing analytics in a database you already know.

InsightsTrack has the same property plus a built-in read-only SQL editor, so exploratory queries do not require database credentials or a separate client. Results export to CSV, and scheduled reports can email them on a cadence. Both are honest answers; Umami's is simpler, InsightsTrack's is more self-service.

Migrating between them

There is no importer in either direction, and building one is harder than it sounds — the session definitions differ, so historical numbers would not line up even with a perfect row-for-row copy.

The workable approach is to run both for two to four weeks:

1. Add the second script alongside the first. Both are async and cookieless; two trackers will not meaningfully affect page performance.

2. Compare trends, not absolute totals. Direction and relative page rankings should agree closely.

3. Expect 5–15% differences in visitor counts. Bot filtering and session-timeout rules differ between every analytics tool (metrics explained).

4. Keep the old tool running through at least one full monthly reporting cycle before cutting over.

If the two disagree by more than about 20%, something is misconfigured — usually a script missing from a subset of pages, or one tool filtering bots the other counts.

Frequently asked questions

Is Umami or InsightsTrack faster?

For collection, both are negligible — Umami's script is smaller. For reporting, it depends on data volume. Below a few hundred thousand events, both feel instant. Above that, InsightsTrack's columnar reads pull ahead on wide date ranges, because a 90-day aggregation reads only the columns it needs instead of walking rows. Below that threshold the difference is not worth switching for.

Can I use Umami and InsightsTrack together?

Yes, and it is the recommended way to evaluate them. Both are cookieless and async, so running both costs one extra network request per page.

Does either require a cookie banner?

Neither sets cookies. Whether you still need a banner depends on your jurisdiction and what else your site stores — several regulators treat any device storage as in scope regardless of mechanism. See the GDPR guide.

Which has better support for multiple sites?

Umami's multi-tenancy is more established. InsightsTrack supports multiple sites with per-site team roles, but Umami has more production mileage running many sites on one install.

Why would I pick Umami over InsightsTrack?

If traffic counts answer your questions, Umami is the smaller, simpler, more proven tool, with a lighter script. That is a good reason and this comparison should not talk you out of it.

How to decide

Choose Umami if traffic numbers are all you need, if you want the smallest possible stack, if script weight matters, or if you value a larger community.

Choose InsightsTrack if you want heatmaps, Web Vitals, and error tracking in one place; if you want SQL access; or if your event volume is large enough that row-store aggregations have started to drag.

Running both

Both are a single script tag and both are MIT, so trying them together costs nothing but a week. The numbers will differ slightly — every tool defines sessions and filters bots differently (metrics explained). See also the full roundup and vs Plausible.