Which fits a team weighing Honeycomb against SigNoz
If your renewal or event-based pricing is pushing you to reconsider Honeycomb, the short answer is this: Honeycomb fits a team that wants a managed service and can live with its 60-day event window, while SigNoz fits a team that needs control over retention, data location or licensing and is willing to run ClickHouse. Honeycomb takes the operating burden off your engineers. SigNoz moves it onto your team in exchange for control over how long traces stay and where they sit. Neither choice changes your instrumentation, because both ingest OpenTelemetry data, which keeps the migration decision separate from the instrumentation work.
The decision turns on four things. First, retention: if audit, incident review or compliance needs require traces beyond 60 days, SigNoz on your own storage is the more direct route, although you must size ClickHouse disk for that window. Second, trace volume: every span counts toward Honeycomb's event-based cost, so estimate your span rate from a representative week before comparing, and ask SigNoz for a sizing review of ClickHouse for the same volume. Third, in-house capacity: you need people who can patch, upgrade, back up and scale ClickHouse and the SigNoz components, and that work recurs for as long as you run it. Fourth, identity and compliance: the SigNoz pricing page lists SAML only on its Teams and Enterprise plans, and it does not list SOC 2 or HIPAA compliance for the Community Edition. If you need those, confirm with SigNoz whether a paid tier covers them, or plan the controls and evidence yourself for a self-hosted deployment, and have your auditor review that plan.
Before you commit, run both backends in parallel for a representative workload, measure your real span volume against your retention target, and write down who owns the self-hosted stack after go-live. If the answer to the last question is unclear, a managed service may still be the better choice even when the licensing and data location arguments favor SigNoz. Your written scope with an implementation partner should state the retention period, the compliance evidence you need and the support model, so the comparison rests on your numbers rather than on the vendor's documentation alone.
Which option fits which scenario
This table maps common decision drivers to the better fit between Honeycomb and self-hosted SigNoz on ClickHouse. Read each row against your own retention needs, data residency rules, team skills and compliance obligations. The main takeaway: Honeycomb suits short retention with no operating load, while SigNoz suits longer history, regional control and existing OpenTelemetry pipelines, at the cost of running the stack.
| Scenario | Better fit | Why |
|---|---|---|
| Short retention is acceptable | Honeycomb | Honeycomb keeps events for 60 days, which covers short debugging windows without you running any storage. |
| Audit or incident review needs longer history | Self-hosted SigNoz | You set retention and storage sizing yourself. Storage cost grows with span volume and retention, so model it from your own traffic. |
| Data must stay in your own region | Self-hosted SigNoz | You choose where the ClickHouse cluster runs. Confirm Honeycomb's regional options against your residency rules before deciding. |
| Small team with no ClickHouse experience | Honeycomb | Honeycomb is operated by its vendor. Self-hosting SigNoz means someone must own ClickHouse backups, scaling and upgrades. |
| Team already runs OpenTelemetry collectors | Self-hosted SigNoz | Existing collector pipelines can add an OTLP exporter for SigNoz, so application instrumentation stays unchanged during cutover. |
| SAML or compliance attestations are required | Depends on plan and controls | SigNoz Community has no SAML, SOC 2 or HIPAA. SAML is on SigNoz Teams and Enterprise plans. For self-hosted deployments, confirm which attestations apply and who supplies the evidence. |
How SigNoz stores traces on ClickHouse and what that means for querying
In SigNoz, the SigNoz OpenTelemetry Collector receives telemetry from your services and writes it to ClickHouse, a column-oriented database. An API server serves the React frontend and the query APIs, and Alertmanager handles alert deduplication, grouping and notification. That split matters for this comparison because Honeycomb runs its own event store as a hosted service, while with SigNoz the storage engine, its schema and its sizing are your team's responsibility. Before you commit, decide who owns ClickHouse capacity, backups and upgrades, and confirm the deployment model you plan to use (Docker Standalone, Docker Swarm or Kubernetes with Helm) against the SigNoz self-host installation guide.
High-cardinality querying in SigNoz depends on how ClickHouse is sized and how the trace schema is laid out, not on a single setting. Attribute-heavy spans, many distinct values per attribute and wide time ranges all add read and storage load, and the result depends on your own span volume, query shapes and hardware. Ask SigNoz for its sizing guidance for your expected spans per second and attribute count, and ask how the schema handles the attributes you filter and group by most often. Do not treat any vendor sizing figure as a promise for your workload.
Keep claims about Honeycomb's query engine general in your evaluation, and write down the queries your engineers run during an incident: grouping by a user or tenant identifier, filtering on a rare error attribute, comparing latency across a deploy and computing percentiles over long windows. Run those same queries against a SigNoz instance loaded with a representative sample of your production OpenTelemetry data, and measure response time at peak span volume. Check the results against what your on-call team needs to find a root cause, not only whether the query returns.
Where data lives and who controls it
Honeycomb and SigNoz differ most in where telemetry is stored and who runs the storage. Each card below covers one decision: where the data sits, who operates it, which identity options apply and what compliance evidence you can expect.
Honeycomb hosted data and retention
Honeycomb stores your events in its hosted service, so retention, region and deletion follow its plan terms. Honeycomb keeps events for 60 days, and longer history is sold as an Enterprise add-on. Ask Honeycomb in writing where data is stored, which regions it offers, how deletion requests are handled and what happens to data at contract end. Those answers determine how much history you can export before you leave.
SigNoz Community on your servers
The Community Edition is MIT-licensed code that you install with Docker Standalone, Docker Swarm or Kubernetes with Helm. Your team holds the ClickHouse storage, the collector endpoint and the backups, so telemetry stays inside your network. The trade-off is that your team also owns patching, scaling and recovery. Confirm the install method and storage sizing with your platform team before you choose it.
SigNoz Cloud regions
SigNoz Cloud runs data centers in the US, EU and India, and its Teams plan starts at $49 a month including $49 of usage. Pick the region before you send any data. Ask SigNoz which region holds your traces, logs and metrics, and whether backups stay in that region. If a residency rule names a country, confirm the site in writing and ask whether moving data later requires reingestion.
SigNoz Enterprise deployment models
SigNoz Enterprise starts at $4,000 a month and comes in three forms: SigNoz Cloud Dedicated, BYOC managed by SigNoz in your cloud account, or self-hosted with enterprise support. In the self-hosted form, your team runs infrastructure, storage, scaling, upgrades and backups. Ask who runs upgrades and backups in each option. Also ask which model keeps the data plane in your account and who controls the storage keys.
SSO and SAML access
SigNoz lists SSO on every plan, including the Community Edition, while SAML is available only on Teams and Enterprise. If your identity provider requires SAML, plan the tier before the pilot. Confirm which login methods your access reviews depend on, and test role mapping with a small group of users before you roll it out.
Compliance evidence and auditors
The SigNoz pricing page states that the Community Edition does not include SOC 2 or HIPAA compliance. Audit reports come from independent auditors, who assess your environment and the vendor's controls, and neither SigNoz nor DeployOpen issues them. DeployOpen can prepare configuration, access and logging evidence for your assessment. Ask your auditor which controls they will sample before you decide where the platform runs.
What SigNoz Community and Enterprise licensing means for you
Before you commit to SigNoz, decide which features your team depends on, because SigNoz is open core: code outside the ee/ and cmd/enterprise/ directories is MIT licensed, while code inside those directories falls under a separate enterprise license. The MIT portion is what the free, self-hosted Community Edition runs on. Read the repository LICENSE file and the ee/LICENSE file in the same repository, and have your legal team confirm which terms apply to the build you deploy, since the split is defined by directory rather than by feature name.
According to SigNoz's pricing page, the Community Edition includes APM and tracing, log management, infrastructure monitoring, alerting and LLM monitoring. It does not include SAML, SOC 2 or HIPAA compliance support, anomaly detection or prebuilt integrations, and community support is limited to Slack. If your identity team requires SAML, your audit team expects SOC 2 or HIPAA evidence from the vendor, or you rely on anomaly detection or prebuilt integrations, map each requirement to a plan before you start the migration. SSO is listed on every plan, including Community, so confirm with SigNoz whether your identity provider flow is covered by that rather than SAML.
Plan for the gaps in writing. Ask SigNoz which Enterprise capabilities are shipped from the enterprise directories and whether any of them are needed to meet your controls. Because Community support is Slack only, record who on your team owns upgrades, incident response and ClickHouse operations, and budget for that internal effort. Enterprise pricing and support terms come from a direct quote, so ask for them in writing, and treat any compliance evidence you need as something your own auditor must assess.
How a move from Honeycomb to SigNoz typically runs
The sequence moves traces, queries and alerting from Honeycomb to a self-hosted SigNoz instance without a gap in coverage, and leaves you with a tested cutover and a retired Honeycomb account.
Inventory services, boards, triggers and SLOs
Your platform or observability team lists every service sending data to Honeycomb, every board, trigger and SLO, and the people who rely on each one. Record which SDKs and OpenTelemetry Collector pipelines feed each dataset, since Honeycomb ingests OpenTelemetry and that determines how much exporter work is needed. The step is done when the list is agreed with the on-call owners and each item is marked keep, rebuild or retire.
Stand up SigNoz in a test environment
Install SigNoz in a non-production environment using one of the documented self-host paths, such as Docker Standalone, Docker Swarm or Kubernetes with Helm. Your infrastructure team owns the cluster, storage, TLS, authentication and backup settings, and SigNoz Community Edition is free to run. The step is done when the UI loads, a test service appears, and the team has confirmed which SSO and access controls they need, since SAML is listed only on the Teams and Enterprise plans.
Send OTLP to both backends during cutover
Add a second exporter in the OpenTelemetry Collector so the same spans, metrics and logs go to Honeycomb and to SigNoz at once. Honeycomb continues to serve your current on-call workflow while SigNoz builds its own history. Review the Collector configuration best practices for authentication and secrets before adding endpoints. The step is done when a sample of services shows matching span counts in both backends over a period your team agrees is representative.
Export the Honeycomb history you need
Decide which historical data must leave Honeycomb before its 60-day event window closes, such as incident traces tied to open reviews or compliance evidence. Confirm with Honeycomb which export options your plan includes, since the Query Data API sits on the Enterprise plan. Store exported data in a location your security team approves. The step is done when the export list is signed off and the files are verified as readable.
Recreate dashboards, alerts and SLOs in SigNoz
Rebuild each kept board using SigNoz's Query Builder, PromQL or ClickHouse SQL, depending on what the query needs. Recreate triggers as SigNoz alerts with notification routing, and rebuild SLOs with the same targets and windows your service owners agreed. Test each alert against a known condition so that a silent failure does not reach production. The step is done when every kept item has a named owner and a test result recorded in your change log.
Size ClickHouse from observed span volume
Use the span and sample volumes observed during dual shipping to size the ClickHouse storage, compute and retention settings. Your platform team sets retention to match your audit and incident review needs, which can differ from Honeycomb's 60 days. Plan upgrades and backups as recurring tasks owned by your team. The step is done when a capacity review shows headroom for expected growth and the retention policy is written down and approved.
Cut over and decommission Honeycomb
Remove the Honeycomb exporter from production Collector pipelines once the SigNoz dashboards and alerts match what the on-call team relies on. Keep the Honeycomb account read-only for a short period your compliance lead approves, then close it and remove stored API keys. The step is done when no production service sends data to Honeycomb, the final export is archived, and the decommission record is complete.
What drives the total cost on each side
Honeycomb and self-hosted SigNoz charge for different things. One side bills for the telemetry you send and the plan you pick, the other moves the bill to hardware, storage and the people who run the stack. Use these cards to build a like-for-like quote before comparing totals.
Honeycomb subscription and event volume
Honeycomb's cost follows the number of events you send, and every span counts toward that volume. Sampling decisions, the number of services instrumented and the length of retained history all move the bill. Check how the plan handles usage past its limits, including throttling, since dropped or delayed telemetry during an incident can be more costly than the overage itself. Ask for the events-per-month estimate your current OpenTelemetry pipeline produces, not an average.
SigNoz Community software cost
The Community Edition carries no license fee, so the cost is the infrastructure underneath it: compute for the OpenTelemetry Collector, API server and Alertmanager, plus ClickHouse nodes and disk. Storage grows with span volume and the retention period you set, so retention is a decision with a direct price. Confirm the sizing with your own span volume and ask your team to test ingest and query load before committing to hardware.
SigNoz Enterprise subscription
SigNoz Enterprise starts at $4,000 a month according to the SigNoz pricing page. In the self-hosted option with enterprise support, your team still runs the infrastructure, storage, scaling, upgrades and backups, so the subscription adds support and features without removing operating work. The BYOC and Dedicated options move more of the operation to SigNoz. Ask which of these models the quote covers and what it includes for SAML and compliance features.
SigNoz Cloud Teams plan
The Teams plan starts at $49 a month including $49 of usage, according to the SigNoz pricing page. Logs and traces are billed at $0.30 per GB ingested with 15-day retention, and metrics at $0.10 per million samples with 1-month retention. Usage beyond the included amount is billed at those rates, so a quote should state the expected GB and sample volumes and the retention period needed for your incident reviews.
Engineering time and migration effort
Operating either side takes people. On the self-hosted side, budget engineering hours for capacity planning, ClickHouse tuning, on-call for the observability stack itself, and backup verification. The one-time cost covers rebuilding boards, triggers and SLOs in SigNoz and running OTLP to both backends during cutover. Ask the vendor or partner for a written scope of these tasks, the named roles and the hours assumed, so you can compare them with your current Honeycomb administration time.
Recurring upgrades and support
Self-hosted SigNoz releases arrive on a regular cadence, and each upgrade of the platform and the OpenTelemetry Collector needs testing against your pipelines and dashboards. Those upgrades recur for the life of the deployment and sit in your team's calendar. Ask whether support is community-only or covered by a contract, what response expectations apply, and who patches the underlying hosts and ClickHouse between upgrades.
Questions buyers ask before choosing between Honeycomb and SigNoz
How much effort does it take to run a self-hosted SigNoz?
Running SigNoz yourself is mostly an operations commitment, not a licensing one. The Community Edition is free to use, but your team carries the installation, storage, scaling, upgrades, backups and monitoring of the platform. SigNoz documents Docker Standalone, Docker Swarm and Kubernetes with Helm as install paths, so the choice of platform drives much of the work. Effort rises with span volume, the number of services sending data, how many people need access, and how often you upgrade. Ask your team to estimate these drivers against your own traffic before comparing options with Honeycomb's hosted service.
Can a small team operate ClickHouse behind SigNoz?
A small team can run it, but ClickHouse becomes the component that needs the most care. SigNoz's architecture stores telemetry from its OpenTelemetry Collector in ClickHouse, a column-oriented database, so storage sizing, disk growth, query performance and backups all depend on how it is set up. Confirm whether at least one person on your team has database operations experience, who is on call for storage incidents, and how restores are tested. Where that skill is missing, the work is usually scoped as a separate item in the engagement.
How long does a migration from Honeycomb to SigNoz take?
The duration depends on scope, and it must be confirmed in a written plan before work starts. The main drivers are how many services and exporters must be repointed, how many boards, triggers and SLOs must be recreated in SigNoz, whether data must be dual-shipped for a period, and how much ClickHouse sizing and testing is needed. DeployOpen does not publish a fixed timeline. Most engagements are fixed-scope, so the duration appears in the agreed scope and deliverables.
Does SigNoz Community include SAML and SOC 2 compliance?
No, SigNoz Community does not include SAML, SOC 2 or HIPAA compliance. SigNoz's pricing page lists SSO on every plan, including Community, while SAML is available only on the Teams and Enterprise plans. The same page says Community support is through community Slack only. If your organization needs SAML or a SOC 2 report for SigNoz itself, confirm those requirements with SigNoz directly. DeployOpen can prepare your own controls and evidence for a compliance assessment, but it does not issue audit reports or attestations.
Can trace history be kept longer than 60 days, and what does it cost?
Yes, a self-hosted SigNoz lets you set retention yourself, so trace history is limited by storage rather than by a plan limit. Honeycomb keeps events for 60 days, and longer retention is sold as an Enterprise add-on. The storage cost depends on span volume, the size of attributes you capture, compression in ClickHouse, and the retention period you choose. For a price comparison, SigNoz Cloud's public pricing lists $0.30 per GB ingested for logs and traces at 15-day retention, but that is a hosted rate, not a self-hosted cost. Ask for a storage model based on your own volumes.
Can our existing OpenTelemetry instrumentation be reused?
Yes, in most cases. OpenTelemetry is vendor-neutral and is not itself a backend, so the SDKs and instrumentation in your applications stay the same when the destination changes. The main change is the exporter configuration, which points the OpenTelemetry Collector at the new endpoint. Trace APIs and SDKs are stable in most languages, while log SDK maturity varies by language, so check the status of each language you use. Some Collector components have mixed stability levels, so review the README for each one in your pipeline.
What work does our team need to supply?
Your team typically supplies the knowledge of its own services and environment, access to the systems that will run SigNoz, and decisions that only the organization can make. That includes which services and environments send telemetry, which dashboards, alerts and SLOs must be recreated, who receives alert notifications, retention and access rules, and the window for cutover. Your team also needs to confirm the hosting target, such as Kubernetes or Docker, and who will own upgrades and backups after handover. A written scope should list these responsibilities explicitly.
Can DeployOpen run the migration alone, or with our team?
DeployOpen can do either, and the split is set in the written scope. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. A common arrangement is for DeployOpen to build and document the platform while your engineers take over operations. Ongoing support, upgrades and continuous testing are available as retainers. Confirm which party owns each deliverable before work begins.
How DeployOpen helps evaluate and move to SigNoz
DeployOpen, a Chainscore Labs company, plans, implements and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Honeycomb and SigNoz, we start by testing what your OpenTelemetry data needs in ClickHouse and what your teams actually query, then build and hand over a self-hosted SigNoz deployment you run yourselves.
How we scope
- Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
- We inventory your current OpenTelemetry pipelines, span volumes, boards, triggers and SLOs to define the migration boundary.
- Scope covers the retention, access control and hosting choices you need to confirm before any build begins.
How we build
- We deploy SigNoz with its Collector and ClickHouse in your environment using the install method your platform team prefers.
- We configure dual shipping of OTLP data so history accumulates in SigNoz during the cutover window.
- We recreate dashboards, alert rules and SLO definitions in SigNoz and test them against live telemetry before sign-off.
How we hand over
- You receive runbooks for installation, upgrades, backups and ClickHouse capacity planning written for your environment.
- We document the query equivalents for your key Honeycomb questions so analysts know where each view now lives.
- Knowledge transfer sessions walk your operators through alerting, retention settings and routine maintenance tasks.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover tracking of SigNoz release notes and planned upgrades in your staging environment first.
- Support scope and response expectations are written into the retainer agreement, so you know what to expect before you sign.
