Time for Sentry to retire... Metric is ready to take over.

Disclaimer: this article is written with bias, bile, and tables. The author believes infrastructure should work for you, not the other way around. If you're a Sentry fan - read to the end; you'll have plenty to bring up in the comments.

Act one, in which we buy a ticket to the zoo

Everyone who has ever stood up a self-hosted Sentry remembers this moment. You clone getsentry/self-hosted, run ./install.sh, and go make coffee. You come back, and Docker is still pulling images. You open docker-compose.yml, and the fun begins: time to meet the family.

Here is the official Compose file for release 26.7.2. It contains 65 (sixty-five) service definitions. Sixty-five, Carl! That's not a typo and not an exaggeration for dramatic effect - it's a file from the official repository; open it and count for yourself. Yes, some of them are profiles and one-shot jobs. But even the "production" cast includes: Sentry web, workers (several kinds!), Relay, Snuba (API + consumers), Kafka, ZooKeeper, ClickHouse, PostgreSQL, Redis, Memcached, Symbolicator, Vroom, cron, and so on down the list until your eyes get tired.

Sixty-five services. To catch stack traces. Words fail me.

Let's put this in perspective. A stack trace is text. A JSON document of a few kilobytes. Humanity learned to accept JSON over HTTP around 2005. And to store that JSON and show it in a web UI, Sentry asks you to run a Kafka message broker (with ZooKeeper included, naturally), the ClickHouse columnar analytical database, a separate PostgreSQL relational database, two different caches, the Relay proxy layer, Python queue workers, a standalone Snuba service that translates internal API queries into ClickHouse's dialect, and the Vroom profiler - and that's still not the whole list.

Now, the hardware. The official system requirements:

• 4 CPU cores;
• 16 GB RAM - and that's the minimum; below it the installer flat-out refuses to run;
• 16 GB of swap (yes, swap the size of your RAM - a quiet moment of self-irony);
• 20 GB of disk - to start with; after that, ClickHouse will decide for itself.

Plus a gentle footnote: "32 GB recommended". Battle-scarred operators on the getsentry/self-hosted issue tracker nod along: under real load, a comfortable life starts at 24–32 GB, because ClickHouse alone can bite off 8–12 GB without blinking.

Thirty-two gigabytes of RAM. To watch your side project crash.

For comparison: a machine like that could run half the microservice infrastructure of an average startup! But no - it will be keeping 65 containers warm, so that you can learn about TypeError: undefined is not a function in a timely fashion.

Act two, in which the author puts on a tinfoil hat

Now, the million-dollar question (literally - Sentry's revenue is estimated in the hundreds of millions): is this an accident?

Look at this beautiful mechanism:

1. Sentry is an excellent product. No argument there. The UX is gold-standard, the SDKs are lovely, the ecosystem is huge. You genuinely want to use it.
2. The SaaS version costs money. Prices grow with event volume, and at some point the bill starts resembling the rent on a small property.
3. "But we're open source!" Sentry says. "Take the self-hosted version!" And it hands you a 65-container leviathan that demands a dedicated engineer, 16+ GB of RAM, and nerves of steel.
4. After a month of operating the leviathan, the average team reaches the only rational conclusion: "It's easier to just pay for SaaS."

A heretical thought occurs: what if this homemade monster is part of the sales funnel? The perfect inoculation against self-hosting as a concept. "See how hard it is? Now look at our Team plan - just $26 a month, zero pain."

Let's spice it up. Sentry hasn't been open source in the strict sense for a while: its license is the Functional Source License (FSL 1.1) - "source available", with a ban on competing with Sentry's cloud. So you may look at the code, but building your...