urgentry vs Sentry self-hosted: a 218-operation comparison.

Why this comparison exists at all

Sentry self-host has been the default fallback when the hosted bill stops making sense. That fallback got weaker through 2024 to 2026. The official self-hosted distribution states a 16 GB minimum in the README, and the project’s own issue tracker carries years of reports from operators who needed substantially more to keep the stack stable in production.

A small set of clean-room implementations now speak the same SDK protocol but take a very different shape on disk. urgentry is one of them. The honest question stopped being “should we self-host Sentry?” and became “if we are going to self-host an error tracker, which path fits the hardware we have?”

For most teams, that hardware is one VPS with 1 to 4 GB of RAM. That is the box this comparison is sized against.

The 218-operation claim, and what it does not say

Compatibility claims usually sit somewhere between marketing and hope. “Most of the API works.” “The important parts work.” Those are positions, not measurements.

urgentry’s claim is concrete and source-scanned: 218 of 218 operations in Sentry’s published OpenAPI schema (research/sentry-openapi-schema.json) have a corresponding handler in the Go codebase. The audit is reproducible. The matching file lives in the repository.

What that number does say:

• Every documented Sentry API endpoint has a route on the urgentry side.
• SDK and tooling that ship with the Sentry ecosystem hit endpoints that exist.
• The DSN swap is the only customer-side change for the documented SDK surface.

What it does not say:

• Semantic parity on every endpoint. Some product surfaces are partially modeled, and the compatibility matrix names those as known gaps.
• Parity with private or undocumented Sentry endpoints. The audit is against the published schema only.
• Parity with Sentry’s web UI features. UI parity is a separate axis.

The interesting comparison is shape, not endpoint count. Two products with identical SDK coverage can have very different debugging experiences.

The capability matrix

The table below is the comparison most engineering teams want and rarely get in one place.

A few rows in that table deserve more than a cell. The next two sections cover them.

Where urgentry is behind

A comparison that hides the other side’s wins wastes your time. The places urgentry is behind today:

Session replay playback UX

urgentry implements the full server-side replay surface. Envelope ingestion for replay items. Project-scoped sampling, privacy filters, and size caps enforced at ingest. Canonical replay reads shared by the API and web layers. Manifest, timeline, pane, and asset APIs that drive a scrubber-based player with deep-linkable anchors and linked issue or trace context. Retention restore that rebuilds canonical indexes. A deterministic replay corpus with regression tests.

What it does not have today is full feature parity with Sentry’s web playback UX. Keyboard shortcuts, network-tab integration, console replay sync, and several of the more polished review affordances are not all there yet. If session replay is the centerpiece of how your team debugs production, Sentry self-host wins.

Continuous profiling product surfaces

The profiling work in urgentry persists canonical profile manifests with sample, frame, and function summaries. Profile data ingests and is readable. The Sentry profiling product surface, with scrubbable flamegraphs and cross-release function-level comparison, is much deeper. If your team uses Sentry profiling today and would miss it, that gap is real.

Enterprise identity past SCIM and basic SAML

urgentry ships SCIM /Users and /Groups lifecycle endpoints plus org-scoped SAML metadata and ACS routes that mint a real browser session after signed assertion validation. That covers the common SAML path. Deeper SSO admin UX, role-based access control mapped from IdP groups, and some enterprise governance features are not there yet. If you have an enterprise IdP team running a SSO migration on a deadline, plan accordingly.

HA across multiple regions

urgentry is a single-host system by design. SQLite plus Litestream is the recommended durability path, and it handles most workloads that fit on one box. Sentry self-host can run across multiple regions with Postgres replication and Kafka failover. If compliance or scale requires multi-region HA, urgentry today is not the answer.

Where urgentry is ahead

On the other side of the matrix, three differences are large enough to change the decision:

Deployment shape

Sentry self-host wires twenty containers together with Docker Compose. Postgres, Redis, Kafka, ZooKeeper, ClickHouse, Snuba split into multiple workers, Symbolicator, Vroom, Relay, web, worker, cron, ingest-consumer, post-process-forwarder. Bringing the stack up is a five-minute affair on hardware that fits, longer on hardware that does not.

urgentry is one binary plus one SQLite file. ./urgentry serve --config urgentry.toml & is the operational truth. No orchestration. No service discovery. No inter-container networking failure mode. The thing you back up is the SQLite file. The thing you upgrade is the binary.

Memory floor

The documented 16 GB minimum for Sentry self-host is the aggregate baseline of twenty processes. ClickHouse alone wants 12 GB on real workloads. The urgentry measured floor under steady ingest at 400 events per second is around 52 MB resident memory, with peaks around 68 MB during compaction. The 300x difference is real, and it shows up in the price tier of host you can run on.

OTLP-native ingest

urgentry implements OTLP/HTTP JSON ingest for traces and logs as a first-class path. Sentry routes OTLP through Relay and Snuba with a translator layer. Both work. The urgentry path has fewer hops and behaves like a normal OTLP destination for the routes it implements, which matters if the rest of your observability stack expects to talk OTLP directly.

Reproducible hardware footprint

Those numbers above are easy to claim. Here is how to reproduce them.

urgentry steady-state at 400 events per second:

# 1 GB Hetzner CPX11, Ubuntu 24.04, SQLite WAL mode
./urgentry serve --config urgentry.toml &
urgentry-bench --events-per-sec 400 --duration 5m
ps -o rss= -p $(pgrep urgentry) \
  | awk '{ sum += $1; n++ } END { print sum/n/1024 " MB avg" }'
# 52 MB avg

Sentry self-host first boot on a 16 GB host:

# 16 GB host per project README
git clone https://github.com/getsentry/self-hosted
cd self-hosted && ./install.sh
docker compose up -d
docker stats --no-stream \
  | awk 'NR>1 { sum += $4 } END { print sum/1024 " GB at idle" }'
# 6 to 8 GB at idle, 12 GB+ under ingest

The published numbers and the issue-tracker numbers line up. The 16 GB README minimum is the floor. Sustained ingest moves it.

When to pick Sentry self-host

A comparison that never recommends the other side is marketing. The honest “pick Sentry self-host” cases:

• Session replay playback is the centerpiece of how your team debugs production today.
• Deep profiling product surfaces, with flamegraphs and cross-release function-level comparison, are non-negotiable.
• You need enterprise IdP integration past SCIM and basic SAML on a deadline.
• Compliance or scale demands HA across multiple regions or strict multi-host redundancy.
• You already run a working Sentry self-host investment that is paying for itself, and the question is “should we migrate?” rather than “should we start fresh?”

If any of those describes you, this is not the article that decides your tooling.

The migration shape, in one configuration line

For the other direction, the DSN swap is the cheapest cutover available. Both products speak the Sentry SDK. The change is one configuration line per service:

# before
SENTRY_DSN=https://<key>@o<org>.ingest.sentry.io/<project>

# after
SENTRY_DSN=https://<key>@urgentry.example.com/<project>

The endpoints urgentry implements are the same paths the SDK already calls. Source map and ProGuard upload sequences work with the same release-create plus upload calls. The recommended cutover starts with the alternative path overview and the side-by-side test plan.

What this comparison is not

A few things this article is not trying to do:

It is not a feature-by-feature listing of every checkbox on the Sentry pricing page. Most of those are SDK ingest paths that both products implement.

It is not a benchmark of Sentry’s hosted product. Hosted Sentry is a different product with different operational characteristics. The Sentry pricing snapshot covers that side.

It is not a recommendation against Sentry. If your team is happy on Sentry self-host and the bill is fine, switching for the sake of switching is not the move.

The job here is to tell you which path fits the hardware and workflows you have today.

Frequently asked questions