Datadog vs SigNoz: when each option fits
Start with the decision you are actually facing. A Datadog renewal, per-host or per-GB charges that keep climbing, or a rule that telemetry must stay in a specific location will each point you toward a different answer. Datadog fits teams that want a hosted platform the vendor operates, and it runs in separate regional sites (US1, EU1, AP1 and others), with each site completely independent and data not shareable across sites. SigNoz fits teams that will run an OpenTelemetry-native stack themselves on ClickHouse, or that prefer to buy SigNoz Cloud, where the data center choices are the US, EU and India. Either way, the telemetry is generated by OpenTelemetry, so the instrumentation work is not wasted if you later change backends.
Four drivers should settle most of the choice. The first is data location: confirm which Datadog site or SigNoz Cloud region your data would sit in, and whether self-hosting in your own environment is required. The second is compliance evidence: the SigNoz pricing page says the free Community Edition does not include SOC 2 or HIPAA compliance, so ask SigNoz which controls and reports come with each plan, and ask your auditor what evidence they will accept from a self-hosted system. The third is in-house operating capacity: a self-hosted SigNoz deployment means your team owns the infrastructure, storage, scaling, upgrades and backups, which is recurring work that must be staffed. The fourth is whether SAML is required, because SigNoz lists SAML only on its Teams and Enterprise plans, not the Community Edition. If any of these four drivers is a hard requirement, get it written into the quote before you commit.
Which option fits which scenario
This table matches common buyer situations to the better fit between Datadog and self-hosted SigNoz, with the condition that drives each answer. Read each row by checking whether the condition describes your team, then confirm the reason against your own environment and written quotes.
| Scenario | Better fit | Reason |
|---|---|---|
| No platform operations capacity to run a backend | Datadog | Self-hosting SigNoz means your team runs the ClickHouse storage, Collector, API server, upgrades and backups. If nobody owns that on-call, a hosted service removes that work, or SigNoz Cloud keeps the backend managed by SigNoz. |
| Telemetry must stay in its own region or network | SigNoz (self-hosted) | Datadog runs in separate regional sites that do not share data, so you must pick a site that meets your residency rule. Self-hosting keeps all data in your own infrastructure, including isolated networks; confirm that your chosen SigNoz Cloud data center also meets the rule before using it. |
| SAML is required on the free tier | Neither without a paid plan | SigNoz lists SSO on every plan, but SAML is not in the free Community Edition and requires the Teams or Enterprise plan. Datadog SAML terms depend on your contract, so ask both vendors for the plan that includes it. |
| Already instrumented with OpenTelemetry | SigNoz (self-hosted) | Telemetry sent through the OpenTelemetry Collector or SDKs can point at SigNoz with a configuration change rather than re-instrumentation. Datadog also accepts OTLP, so this row favors the option that keeps your instrumentation portable. |
| Depends on Datadog-specific integrations and features | Datadog | SigNoz does not include prebuilt integrations on the Community Edition, and dashboards must be translated with its migration tool. Teams relying on Datadog-only products, monitors or integrations should list each dependency and confirm its equivalent before committing. |
| Needs enterprise-licensed code paths | Confirm before deciding | Code under the ee/ and cmd/enterprise/ directories uses a separate enterprise license, while the rest is MIT. Have counsel review which features you use, because the licensing line affects what you can run without a commercial agreement. |
How SigNoz keeps traces, logs, metrics and alerts in one application
SigNoz places logs, metrics, traces, alerts, dashboards and exceptions in one application, so one data store and one query layer serve all of them. The flow has four parts. The SigNoz OpenTelemetry Collector accepts telemetry from your services and writes it to ClickHouse, a column-oriented database. An API server serves the React frontend and the query APIs that dashboards, the Query Builder and alert rules call. Alertmanager takes fired alerts and handles deduplication, grouping and notification. Confirm the component layout for your install method in the SigNoz architecture documentation before you size anything, because a Docker Standalone host and a Kubernetes Helm deployment do not run the same topology.
For a buyer, the main consequence is that ClickHouse becomes a storage layer your organization owns. Datadog's data sits in its hosted backend, which you cannot size, replicate, back up or restore yourself. With SigNoz, traces, logs and metrics land in ClickHouse, so you plan three inputs: expected ingest volume for each signal, the retention you need for each signal, and the CPU, memory and disk headroom for query load during an incident. Ask who will run ClickHouse upgrades, schema changes, storage expansion and restore tests. A fault in that layer can take traces, logs and alerts down together, and those operating skills are a recurring cost to include in the staffing comparison before any migration starts.
The two products also differ in what you can inspect. The Datadog Agent source is public: its user space components are Apache-2.0 and its eBPF code is GPL-2.0, so your security team can read what the agent collects and sends from each host. The Datadog backend and UI are not open source, so the storage, query and alerting behavior you depend on can only be tested from the outside. SigNoz's core is in one repository, so your engineers can read the collector, API server and alerting paths. Check the license boundaries for the parts you plan to use, because code under the ee/ directory falls under a separate enterprise license.
Capability comparison from the documented features
This table compares Datadog and SigNoz across deployment, instrumentation, telemetry types, query languages, licensing, SSO and support, using only documented facts. Where a Datadog detail is not in our sources, the cell tells you what to confirm in Datadog's current documentation or with your account team before you decide.
| Capability | Datadog | SigNoz |
|---|---|---|
| Deployment model | Hosted service in separate regional sites (US1, EU1, AP1 and others); each site is independent and data cannot be shared across sites | Self-hosted via Docker Standalone, Docker Swarm or Kubernetes with Helm, or SigNoz Cloud in US, EU and India data centers, or Enterprise BYOC or Dedicated |
| Instrumentation path | Datadog Agent with its DDOT Collector, a standard OpenTelemetry Collector exporting OTLP, or direct OTLP ingestion | OpenTelemetry-native; the SigNoz OpenTelemetry Collector accepts telemetry from many sources |
| APM and distributed tracing | Hosted APM module; confirm current trace feature coverage in Datadog's documentation | APM and distributed tracing listed as built-in features on the Community Edition |
| Logs | Hosted log management; confirm retention and archive options with your account team | Log management included on the free Community Edition, stored in ClickHouse |
| Metrics | Hosted metrics ingested through the Agent or OTLP; confirm current limits in Datadog's documentation | Metrics stored in ClickHouse and queryable with PromQL or the Query Builder |
| Alerting | Hosted alerting; confirm monitor types and notification routing in Datadog's documentation | Alertmanager handles deduplication, grouping and notification; alerting included on the Community Edition |
| Dashboard query languages | Datadog query language; confirm current options and any import tooling in Datadog's documentation | Query Builder, PromQL or ClickHouse SQL |
| Backend licensing | Backend and UI are not open source; the Datadog Agent user space is Apache-2.0 and its eBPF code is GPL-2.0 | Open core: code outside ee/ and cmd/enterprise/ is MIT; code inside those directories is under the enterprise license |
| SSO and SAML | Confirm SSO and SAML options for your plan with your Datadog account team | SSO on every plan including Community; SAML only on Teams and Enterprise plans |
| Support model | Vendor-provided support by plan; confirm response terms with your account team | Community Edition support is community Slack only; enterprise support is a paid tier |
Where telemetry lives and who controls the platform
These four cards cover where telemetry is stored, how the platform is hosted, how users sign in, and what compliance evidence exists. Each one is a decision point in a Datadog vs SigNoz evaluation, and each one changes who in your organization carries the operating load.
Data location and regional sites
Datadog runs as a hosted service in separate regional sites, including US1, EU1 and AP1, and its documentation states that each site is completely independent and data cannot be shared across sites. Choosing a site at onboarding therefore fixes where telemetry lives. SigNoz Cloud offers data centers in the US, EU and India, and self-hosting keeps all telemetry in your own network. Confirm which region your logs, traces and metrics will land in before you sign.
Hosting models and operating load
Self-hosted SigNoz installs with Docker Standalone, Docker Swarm or Kubernetes using Helm, and its docs include Kubernetes guides for AWS, GCP, AKS, OpenShift, Argo CD and Flux CD. Under SigNoz Enterprise, the customer's team still runs infrastructure, storage, scaling, upgrades and backups in SigNoz Cloud Dedicated, BYOC, or self-hosted models. Ask who holds the pager for ClickHouse and the collector before you choose a model.
Single sign-on and SAML
SigNoz lists SSO on every plan, including the free Community Edition, but SAML is available only on the Teams and Enterprise plans. If your identity policy requires SAML federation with your corporate directory, the Community Edition does not meet that requirement. Check whether your identity provider supports the protocol SigNoz offers on your plan, and plan user provisioning and offboarding before rollout.
Compliance evidence and certifications
The SigNoz pricing page says the Community Edition does not include SOC 2 or HIPAA compliance. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the reports. Ask SigNoz for its current compliance position in writing, and confirm which controls your own environment must supply, such as access logging, backups and encryption in transit.
MIT core, enterprise code and what the free edition leaves out
The Community Edition is the free, self-hosted tier of SigNoz. According to the SigNoz pricing page, it includes APM and tracing, log management, infrastructure monitoring, alerting and LLM monitoring. It leaves out SAML, SOC 2 and HIPAA compliance, anomaly detection and prebuilt integrations, and support comes through the community Slack only.
- Included capabilities: APM and tracing, log management, infrastructure monitoring, alerting and LLM monitoring run in your own environment without a license fee.
- Identity limits: SSO is listed on every plan, but SAML is available only on the Teams and Enterprise plans, so a SAML requirement points to a paid tier.
- Compliance limits: SOC 2 and HIPAA are not included in the Community Edition. Your own controls and evidence must cover those areas, and an independent auditor must assess them.
- Missing features: anomaly detection and prebuilt integrations are not included, so you will build those alert and dashboard content yourself.
- Support model: community Slack is the listed support channel, so an internal team or a paid partner must own production incidents.
Before you commit, check the current edition matrix on the pricing page and map each limit against your identity, compliance and support requirements.
SigNoz is open core. According to the SigNoz LICENSE file, code outside the ee/ and cmd/enterprise/ directories is MIT licensed, while code inside those directories falls under the separate enterprise license in ee/LICENSE. The license split is set by directory, so the files you build or deploy determine which terms apply to you.
- MIT scope: everything outside ee/ and cmd/enterprise/ is covered by the MIT (Expat) license, which permits use, modification and redistribution with the notice retained.
- Enterprise scope: code inside ee/ and cmd/enterprise/ is governed by the terms in ee/LICENSE, which can restrict use without a commercial agreement.
- Build check: confirm which directories your chosen release, container image or Helm chart includes, and whether any enterprise-only components are enabled in your configuration.
- Fork check: if you patch or rebuild SigNoz, track which files you change and whether they fall inside the enterprise directories.
- Version pinning: record the exact release you deploy, because license boundaries and included components can change between versions.
Ask your legal team to review the ee/LICENSE terms against your planned deployment, including any internal redistribution or managed-service use.
The Datadog Agent is open source, but the Datadog service is not. According to the datadog-agent GitHub repository, the user space components are Apache-2.0 and the eBPF code is GPL-2.0. The Datadog backend and UI are not open source, so the agent code does not give you a self-hosted Datadog platform.
- Agent user space: these components are Apache-2.0, which permits use and modification with notice and patent terms.
- eBPF code: this code is GPL-2.0, which carries copyleft obligations if you distribute modified versions.
- Backend and UI: these are proprietary and hosted in Datadog's regional sites, so you cannot run them in your own infrastructure.
- Migration implication: replacing the Datadog Agent with an OpenTelemetry Collector changes the agent license, while the backend contract and data location still need separate review.
- Exit terms: review your Datadog agreement for data export, retention and termination terms, since those govern what you can take with you.
Have counsel confirm how each license applies to the agent builds you ship and to the Datadog contract you currently hold.
What a Datadog bill covers and what a self-hosted SigNoz stack costs to run
A Datadog bill is built from several meters, and the reader should start by pulling each line from their own contract rather than from memory or marketing pages. The meters that matter for this comparison are host-based infrastructure charges, APM charges for traced services or hosts, and per-GB or per-event charges for log management, plus any add-ons the team enabled. No Datadog list prices are supplied for this page, so the figures that count are the ones in the order form or renewal, including committed versus on-demand rates, overage terms and how billable hosts or containers are counted. Ask the account team to break the last twelve months of invoices into those meters, because the largest driver is often log volume and retention rather than host count. SigNoz offers two different cost models, and a quote should separate them. SigNoz Cloud's Teams plan starts at $49 a month including $49 of usage, with logs and traces at $0.30 per GB ingested and 15-day retention, and metrics at $0.10 per million samples with 1-month retention, according to the SigNoz pricing page. SigNoz Enterprise starts at $4,000 a month and is offered as SigNoz Cloud Dedicated, as BYOC managed in your cloud account, or as self-hosted with enterprise support. The self-hosted Community Edition has no license fee, but the team pays for the ClickHouse and collector infrastructure, the storage that holds traces, logs and metrics, the staff time for upgrades, backups and scaling, and any support contract. Ask for the retention and ingest assumptions behind any Cloud quote, and for the support scope and response terms of an Enterprise quote. The one-time work is the migration: replacing Datadog agents and libraries with OpenTelemetry, bridging traffic during cutover, translating dashboards and recreating monitors as SigNoz alerts. Running dual pipelines during that window adds temporary cost on both sides. Recurring costs are the storage and compute that grow with ingest and retention, plus the operating time that the self-hosted option moves onto your team. Before comparing totals, confirm which SigNoz features your use case needs, because SAML is not in the free Community Edition, and that gap can push a team toward a paid plan. Ask any vendor or partner quote to list each cost line, its unit, its one-time or recurring nature and the assumptions behind the volume.
How a move from Datadog to SigNoz is usually sequenced
The sequence moves telemetry in controlled stages so that SigNoz shows the same services, dashboards and alerts as Datadog before any Datadog agent is switched off.
Inventory agents, libraries, integrations and dashboards
Your team lists every Datadog Agent deployment, tracing library, log shipper, integration and custom metric in use, plus each dashboard and monitor that depends on them. Record the owner of each service and the environment it runs in. Done means you have one inventory that shows which services emit traces, metrics and logs, which Datadog features each one uses, and which dashboards and monitors would break if their source went silent. Metrics and traces typically have no bulk export from Datadog, so decide now which history you need to keep, where it will live, and who signs off on that decision.
Instrument services with OpenTelemetry
Application teams replace Datadog tracing libraries with OpenTelemetry SDKs and auto-instrumentation, and configure them to export OTLP to an OpenTelemetry Collector rather than directly to Datadog. Trace SDK maturity is stable in most languages, but log SDK maturity varies, so check the status page for each language in your estate before you rely on OpenTelemetry for logs. Done means each service sends traces and metrics to the Collector in a test environment, and the team can see the spans and attributes it expects in a local or staging view.
Bridge existing Datadog hosts through the Collector
Platform engineers run an OpenTelemetry Collector with the Datadog receiver so that hosts still reporting to Datadog and newly instrumented services can be compared during cutover. The Collector can fan data out to SigNoz and, where needed, to Datadog in parallel. Done means both backends show matching service names, span counts and key metric values for the same workloads over a window you agree in advance. Confirm the receiver's supported data types and configuration against the Collector documentation for your release, because mixed stability levels are documented per component.
Stand up self-hosted SigNoz in the chosen environment
Your platform team deploys SigNoz in your own infrastructure using Docker Standalone, Docker Swarm or Kubernetes with Helm, depending on the environment you chose earlier. The deployment includes ClickHouse storage, the query service and the Collector endpoint, with backups, retention settings and access control set before production traffic arrives. Done means a test workload reaches the SigNoz UI, retention matches the history decision from step one, and the team has written down who runs upgrades and restores. Confirm which edition covers SAML and other features you need, since the free Community Edition does not include SAML.
Translate dashboards and recreate monitors as SigNoz alerts
Engineers export dashboard definitions from Datadog as JSON, use SigNoz's migration tooling to translate what it supports, and rebuild the rest with the Query Builder, PromQL or ClickHouse SQL. Each Datadog monitor becomes a SigNoz alert with the same threshold, evaluation window and notification route, tested against known conditions. Done means every critical dashboard renders the same signals as its Datadog original, and each alert has fired in a test or been confirmed against a known event, with the notification path verified.
Cut over, validate parity and decommission Datadog agents
The team moves production services to the OpenTelemetry pipeline in agreed groups, runs both backends in parallel until dashboards, alerts and on-call routing match, and then switches Datadog agents off host by host. Records of final Datadog dashboard JSON, monitor definitions and any archived data are kept in your own storage. Done means every service reports only to SigNoz, every critical alert has a tested route, the parity checklist is signed by the service owners, and the Datadog agents, API keys and integrations are removed and the account's data retention obligations are confirmed in writing.
Questions buyers ask before choosing or hiring help
What drives the cost and effort of moving from Datadog to SigNoz?
The cost is driven by how much telemetry and how many services move, not by the license, because SigNoz Community Edition is free to run. Costs fall into four groups: infrastructure to run the ClickHouse-backed stack and its Collector, staff time for instrumentation and dashboard rebuilds, a period of dual running while both platforms receive data, and support. Recurring costs are compute, storage and retention plus the people who operate the stack. Ask any quote to itemize instrumentation work per service, dashboard and monitor rebuilds, cutover and dual running, and whether the scope includes ongoing upgrades. If you want SigNoz Cloud or Enterprise instead, ask for the current SigNoz pricing page figures at the time you decide, since those are vendor prices rather than DeployOpen prices.
How long does a migration from Datadog to SigNoz take?
The duration depends on the number of services, languages, dashboards and alerts, and on how much of the Datadog estate depends on Datadog-specific agents or libraries. Teams that already run OpenTelemetry SDKs usually have less to change than teams on proprietary tracers. We do not publish a generic timeline, so agree the duration and milestones in the written scope before work starts. Ask for phases with exit criteria: inventory, pilot service, dual shipping, dashboard and alert parity checks, and decommissioning Datadog agents. Your own change freezes and approval cycles often set the pace more than the technical work.
What does the migration need from our own team?
The work needs named owners on your side before it starts. Platform engineers own the Collector deployment, ClickHouse storage, network paths, retention and backups. Application teams own OpenTelemetry instrumentation in their code and must verify that traces and logs carry the attributes their dashboards need. Someone with authority must decide where telemetry is stored, how long it is kept, who can see it and whether SigNoz Community Edition, Teams or Enterprise fits your access and compliance needs. Security should review Collector authentication and exporter credentials. Without these decisions, dual running tends to stall.
Can our team migrate from Datadog to SigNoz without a partner?
A capable platform team can do the work alone, especially for a small estate with mostly OpenTelemetry-ready services. Partners usually help where the work is repetitive or risky: standardizing Collector pipelines across many services, bridging with the Collector's Datadog receiver during cutover, translating dashboard JSON with the SigNoz migration tool and checking each rebuilt alert, and running the stack hardened and backed up. Be aware that SigNoz Community Edition support is community Slack only, so your team carries operational support unless you buy a plan or an outside retainer. Decide this by comparing your staff capacity with the service count.
Can we get SAML single sign-on without paying for a SigNoz plan?
No. According to the SigNoz pricing page, SSO is listed on every plan, including Community Edition, but SAML is available only on the Teams and Enterprise plans. If your identity provider requires SAML, the Community Edition does not meet that need as documented. Before deciding, confirm with SigNoz which SSO protocols the free edition supports for your identity provider, and check whether the Teams plan's pricing and terms fit your usage. Keep in mind that the SAML requirement is a licensing question, so it should be settled before the architecture is fixed.
Can we keep our Datadog history after moving to SigNoz?
Some history can be kept, but it is not a full copy of everything. Logs are the most portable: Datadog Log Archives can be written to your own object storage as compressed JSON and loaded later for reference. Dashboard definitions can be exported as JSON through the Datadog API and translated with SigNoz's migration tool, though each rebuilt panel needs a check. Metrics and traces generally have no bulk export path, so historical values stay in Datadog for its retention period, and you should confirm current export options with Datadog. Plan to keep Datadog access, or a read-only export, until you no longer need that history for audits or incident review.
How DeployOpen helps evaluate, implement and migrate SigNoz
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For Datadog vs SigNoz, we start with a written scope that fits your telemetry, your licensing constraints and your migration timeline.
How we scope
- Inventory the Datadog agents, APM libraries, log pipelines, dashboards and monitors that are in use today.
- Confirm which SigNoz deployment fits your environment: Docker Standalone, Docker Swarm or Kubernetes with Helm, or self-hosted with enterprise support.
- Agree in writing whether the Community Edition meets your SAML, compliance and support requirements, or whether an enterprise plan is needed.
How we build
- Instrument services with OpenTelemetry and route telemetry through the OpenTelemetry Collector into SigNoz running in your cloud account or data center.
- Configure the Collector's Datadog receiver to bridge data during cutover, and dual-ship telemetry while teams compare results.
- Translate dashboards with SigNoz's migration tooling, recreate monitors as SigNoz alerts, and test sizing against ClickHouse storage and retention needs.
How we hand over
- Deliver architecture, configuration, runbooks for backups, upgrades and scaling, and a record of every dashboard and alert migrated.
- Document the license boundary between MIT-licensed code and enterprise-licensed code so your legal and procurement teams can review it.
- Walk operations staff through the self-hosted runbooks so your team owns day-to-day running of the platform after handover.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends.
- Review each SigNoz release and Collector release before you upgrade, and test changes in a staging environment first.
- Confirm with your team which support tier, retention period and recurring operating cost you want covered in the written quote.
