self-hosted analytics in one binary: the architecture, and whether you should run it yourself

people search for self-hosted analytics because they want four things: to own the data, to keep it out of a shared third-party pool, to stop paying a bill that grows with traffic, and to never be locked in. those wants are all legitimate. the part worth being honest about is that self-hosting is one way to get them, and it is the way that pays in your hours instead of your dollars. smolanalytics is built on the exact architecture self-hosters ask for, one Go binary that stores events itself, no ClickHouse, no Postgres, about 7 bytes per event at rest, but it is commercial and managed: every project runs on its own isolated instance of that binary, nothing phones home, and your data exports in one file, any time. this post explains the architecture, what running analytics yourself actually costs, and how to decide.

why is most self-hosted analytics so heavy?

because analytics tools grew into event platforms, and event platforms assume a database tier.

Umami is clean open-source web analytics, but the app always needs a database running beside it, and since v3 dropped MySQL, self-hosting means standing up Postgres. that is a second service to provision, back up, patch, and keep alive. the smolanalytics vs Umami page walks through this in detail.

PostHog is the far end of the same axis. self-hosting it means Kafka, ClickHouse, Redis and Postgres, a real cluster. PostHog has publicly said most teams lack the resources to run it reliably, and that a full disk can take an instance down for hours or days. that is not a knock on PostHog; it is what happens when one product tries to be nine.

the pattern is: the analytics is the easy part, and the storage tier is the thing that turns "self-host" into a weekend that becomes a month.

how does one binary store analytics without a database?

the trick is that analytics events are a narrow, append-only workload, and you do not need a general-purpose database for that.

smolanalytics keeps a durable append-log for the hot, recent events on a single box. as events age, the log seals into an immutable columnar segment (compressed, CRC'd, about 7 bytes per event at rest) that lives on disk or object storage. RAM stays flat no matter how much history piles up, because memory is bounded by the seal size, not by total events. there is no separate database process anywhere in the stack.

so the operational reality of one instance is: one binary, one data file. that directory is the entire analytics database, which is exactly why export can be one file: the storage format is documented with compatibility guarantees, and everything you have tracked comes out in one call to CSV or JSONL.

this is the architecture your instance runs on when you sign up. the difference from the self-host pitch is who carries the pager: each project gets its own isolated instance of that binary, provisioned for you, upgraded for you, backed up for you.

what does "~7 bytes per event" mean in practice?

it means storage is never the thing you plan around, and it is a big part of why flat pricing can stay flat.

at roughly 7 bytes per event at rest, a few million events a month is a few tens of megabytes, and 100M events is still well under a gigabyte sealed next to the process. treat those numbers as illustrative; the point is the order of magnitude. a tool that needs a cluster to hold your events has to charge you like it runs a cluster. a tool that stores your year in less space than a phone photo does not.

what will this analytics engine never do? (the honest never-list)

it ships the full toolkit from that same engine (flags, experiments, click heatmaps, surveys, and a session inspector that replays a user's journey from their events), and the never-list is short and stated plainly so you can rule it out fast if it is wrong for you:

• no pixel-perfect DOM session recording. the session inspector reconstructs a journey from events; it does not record and replay the raw DOM the rrweb/video way. other tools do that well; it is a different data shape.
• no data warehouses. this is not a warehouse; it answers questions about your events.
• no multi-node clustering. exactly one writer per instance, which is precisely what makes one-instance-per-project isolation cheap enough to give everyone.

if any single item on that list is a hard requirement for you, pick a heavier tool. that is the correct call, and no amount of "but it's one binary" changes it.

should you self-host analytics at all?

be honest about what you are buying with the hours. self-hosting genuinely wins when the requirement is regulatory ("the data must sit on hardware we control") or when your time is free and your budget is zero. if that is you, the real self-host options are Umami (light, needs Postgres) and PostHog (heavy, needs a cluster), and you should go in expecting to do the backups, upgrades, and 2am disk alerts yourself.

if what you actually wanted was ownership and no lock-in, check whether the managed version already gives you it. here, it does, by design: one isolated instance per project, so your events never sit in a shared pool. no phone-home. importers from PostHog, Mixpanel, Amplitude, Umami, CSV, and JSONL on the way in, and a one-file export on the way out, so leaving is always one call. the worst case is you export everything and go, which is the same worst case self-hosting promises, minus the server you had to run to get it.

the price is flat and public: a 14-day full trial at Pro limits with no card, then $19/month on Pro (2M events) or $49 on Scale (5M), $6 per million past that, and the dashboard never locks.

if you want the one-binary architecture without becoming its operator, start the 14-day trial and your instance is up before a self-host would have finished picking a VPS. or compare against what you run now on smolanalytics vs Plausible and smolanalytics vs Umami.