GoatCounter vs Umami

GoatCounter and Umami are the two featherweights in this hub — the picks for someone who wants to know how the site is doing and wants nothing else to run. Both are cookieless, both fit in one short compose file, and both sit far below the 2 GB floor of the ClickHouse-backed tools. They differ on how small "small" is, and on how much dashboard you get for it.

How small is small

GoatCounter is a single statically compiled Go binary — or the project's own Docker image — writing to a SQLite file in one named volume. There is no second container. The README says the release binaries "contain everything you need" and that "the only dependency is somewhere to store a SQLite database file or a PostgreSQL connection." It publishes no RAM figure; the 256 MB on our page is our estimate, and it is generous.

Umami is a Next.js application that wants a PostgreSQL container beside it. Two containers, one compose file, 1 GB on our page. Still tiny by the standards of this hub, but it is an application with a database, where GoatCounter is a process with a file.

How much dashboard you get

Umami gives you the modern single-page analytics dashboard: pageviews, unique visitors, referrers, top pages, countries, devices — plus custom events that carry data properties, and the funnels, retention and heatmaps its MIT build includes. That is the layer that separates "a counter" from "analytics" for most small projects. One script tag on the site and you are done; a backend can also POST events to /api/send.

GoatCounter is candid about its scope. Its README positions it for people "confused by the myriad of options and flexibility of Google Analytics and Matomo that you don't need", and what it tracks is: unique visits (via a non-identifying hash, no cookies), referring sites and campaigns, browser, location and screen size, and named events — a count() call with event: true, a path and a title, but no arbitrary properties. What it adds that Umami does not is log-file import from nginx, Apache, Caddy or CloudFront; its JavaScript-free tracking pixel counts pages on your own site, while Umami v3's pixels are separate stats pages meant for emails and third-party sites. Both also accept events from your backend. For a documentation site, a blog, or anything whose readers run script blockers, that flexibility is the point.

Privacy

Both avoid cookies. GoatCounter goes further in what it claims: the README says it "doesn't need a GDPR notice", and the project's GDPR page explains why — "no personally identifiable information is collected" — while adding the word probably and a reminder that the author is not a lawyer. Umami is cookieless and privacy-focused, and leaves the legal conclusion to you.

Licenses

Umami is MIT. GoatCounter is EUPL-1.2 — the European Union Public Licence, with a modified "Compatible Licenses" appendix that the LICENSE file says is otherwise identical to the standard text. Both are free-software licenses; MIT is the one nobody has to look up.

Pick Umami if…

• You want events with properties, funnels and retention and a modern dashboard your teammates will read without a tutorial.
• You are fine running PostgreSQL beside the app.
• You want the license nobody questions (MIT).

Pick GoatCounter if…

• You want the smallest possible thing: one binary or one container, SQLite, no database server.
• Your readers block JavaScript and you want the tracking pixel, or you would rather import server logs than add a script tag at all.
• You want the tool whose author has already written the GDPR reasoning down for you.

The honest trade-off

Umami wins this comparison for most self-hosters because events with properties, funnels, retention and a dashboard people actually read are worth one extra container, and 1 GB is the smallest VPS tier anyway. GoatCounter is the better pick when minimalism is the requirement rather than a preference: it is the only tool in this hub that runs as a single process on a SQLite file, counts visitors with no JavaScript at all, and says in plain words what it does not do.