Hey HN, I'm Pascale. I built HitKeep because I got frustrated maintaining a multi-service stack just to count page views.
Every self-hosted analytics tool I tried needed PostgreSQL, ClickHouse, Redis, or some combination. For a handful of sites, that's a lot of moving parts to babysit.
HitKeep is a single static Go binary (~80 MB) that embeds everything:
- DuckDB for columnar OLAP storage — the entire database is one file, ~120 MB per million hits
- NSQ as an in-process message broker — the HTTP handler enqueues a hit in microseconds, a background consumer batches writes to DuckDB via the appender API
- The Angular dashboard and 2 KB tracking script are compiled into the binary via `embed.FS`
You download it, run it, done. No docker-compose with 4 services. One process, one data directory. Idles at ~50 MB RAM on a $6/month VPS. (okay, realistically, you'd add a proxy)
The trickiest engineering decision was write contention.
DuckDB is single-writer, so writing synchronously per HTTP request doesn't work under load. Embedding NSQ in-process solved this: the ingest handler publishes to memory, and a consumer resolves the correct tenant store, groups messages into micro-batches, and flushes them through DuckDB's appender API.
The write path completes without the HTTP request ever blocking on disk.
In the last three weeks, I added ecommerce analytics, team management with RBAC, period-over-period comparison, email reports, and more. The full changelog is on GitHub.
MIT licensed. There's a managed cloud option (EU/US) for teams that don't want to self-host, but the OSS binary is the complete product.
Curious what HN thinks about DuckDB as a self-contained OLAP backend for this kind of workload. Has anyone else hit the single-writer wall and solved it differently?
Hey HN, I'm Pascale. I built HitKeep because I got frustrated maintaining a multi-service stack just to count page views.
Every self-hosted analytics tool I tried needed PostgreSQL, ClickHouse, Redis, or some combination. For a handful of sites, that's a lot of moving parts to babysit.
HitKeep is a single static Go binary (~80 MB) that embeds everything:
- DuckDB for columnar OLAP storage — the entire database is one file, ~120 MB per million hits
- NSQ as an in-process message broker — the HTTP handler enqueues a hit in microseconds, a background consumer batches writes to DuckDB via the appender API
- The Angular dashboard and 2 KB tracking script are compiled into the binary via `embed.FS`
You download it, run it, done. No docker-compose with 4 services. One process, one data directory. Idles at ~50 MB RAM on a $6/month VPS. (okay, realistically, you'd add a proxy)
Live demo: https://demo.hitkeep.com/share/7a55968bb42df256512fbe7ff73ab... (read-only share link with real data — no login needed)
The trickiest engineering decision was write contention.
DuckDB is single-writer, so writing synchronously per HTTP request doesn't work under load. Embedding NSQ in-process solved this: the ingest handler publishes to memory, and a consumer resolves the correct tenant store, groups messages into micro-batches, and flushes them through DuckDB's appender API.
The write path completes without the HTTP request ever blocking on disk.
In the last three weeks, I added ecommerce analytics, team management with RBAC, period-over-period comparison, email reports, and more. The full changelog is on GitHub.
MIT licensed. There's a managed cloud option (EU/US) for teams that don't want to self-host, but the OSS binary is the complete product.
Curious what HN thinks about DuckDB as a self-contained OLAP backend for this kind of workload. Has anyone else hit the single-writer wall and solved it differently?
GitHub: https://github.com/pascalebeier/hitkeep
Docs: https://hitkeep.com