Skip to content

Compare

Auditty vs Edge Delta

Edge Delta is the closest thing to Auditty architecturally. Both process logs on the node before they leave, both detect patterns automatically, and both can archive the raw stream.

The difference is how much product arrives with it. Edge Delta is a platform you could plausibly move onto; Auditty is a component that makes the platform you already pay for cheaper.

Edge Delta wants to be your observability platform. Auditty wants to lower its bill.

Edge Delta ships its own search, dashboards, service maps and an incident-response layer, and its own destination is not optional if you want that interface to work. That is a coherent product and for some teams it is the right one. Auditty deliberately has no such ambition: it forwards to the SIEM or log vendor you already run, writes the rest to your own storage, and is designed to be removable in an afternoon with your logging returning to exactly what it was.

Side by side

5 questions a buyer actually asks.

Every claim about Edge Delta below is a quote from their own documentation, with the link. We would rather you checked than took our word for it.

What does the agent cost me per node?

Auditty

1.5 vCPU and 768 MiB, enforced rather than advisory. It cannot exceed that whatever the log volume, and it does not grow into the space your workloads need.

Edge Delta

Edge Delta publishes typical consumption per agent plus a memory multiplier over throughput, and the node install includes more than one component. Their own guidance is the clearest source here.

CPU: 0.2-0.5 vCPU per agent (per node) […] Memory: 500MB-1GB per agent […] Pipeline Memory Multiplier: ~2.4x (e.g., 50GB/day data volume ≈ 120GB in pipeline memory)
Edge Delta documentation, Reduce agent resource consumption · source

How many moving parts is that?

Auditty

One DaemonSet, plus one in-cluster service that is the only component with an outbound route. One thing to allow-list, one place to audit.

Edge Delta

A node pipeline is several agent types, with compactor and rollup enabled by default, and gateway and coordinator tiers are separate charts that some features require.

Edge Delta supports multiple types of agents: Processing Agent: Executes the pipeline logic. Compactor Agent: Compresses and encodes telemetry data into efficient formats. Rollup Agent: Aggregates metric data to reduce frequency and cardinality
Edge Delta documentation, Architecture · source

Who owns the archive?

Auditty

You do, from the first install, with no other option. Auditty holds no credentials for it and has no network path to it.

Edge Delta

By default the archive that powers Edge Delta’s log search sits in buckets Edge Delta maintains. Archiving to your own bucket is supported as a separate configuration.

This data type represents the compressed storage of raw logs on a cloud storage service, such as S3. Edge Delta maintains separate S3 buckets per customer organization.
Edge Delta documentation, Pipeline settings · source

What does it take to search my own archive?

Auditty

Nothing beyond what is already installed. Retrieval by pattern, time range or field value is part of the product, and every summary carries a link back to the exact lines it replaced.

Edge Delta

Searching archives you host yourself is a distinct deployment called hybrid log search, with its own cluster requirements and a support conversation to enable it.

To deploy hybrid log search, you need a dedicated EKS cluster in your AWS account […] Finally, contact Edge Delta support to enable hybrid log search on your organization.
Edge Delta documentation, Hybrid log search install · source

What does it want on my hosts?

Auditty

Host access, and we do not soften that. Reading other containers’ log files requires it. What we publish instead is the full list of what is requested and the specific thing each item is for, because a reviewer has to be able to check the ask against the use.

Edge Delta

Also host access, with one default worth catching in review: the kernel-level tracer that powers service maps is enabled in the chart out of the box and needs a privileged container to run.

Enable eBPF-based telemetry sources (Kubernetes Trace, Service Map). Requires podSecurity.privileged=true.
Edge Delta documentation, Helm values for the node agent · source

Honestly

Neither of these is the right answer for everyone.

Choose Edge Delta if

  • You want to consolidate. If the plan is to replace the observability backend rather than feed it, Auditty is the wrong shape of product and Edge Delta is a serious candidate.
  • You need traces and service maps as well as logs, including the kernel-level network view their agent can collect.
  • You want incident investigation in the same product that does the reduction.
  • Running several components per node is not a constraint for you, and the resource envelope is comfortable.

Choose Auditty if

  • You are keeping Datadog, Splunk or Elastic and want to keep them. Auditty is additive to that stack and forwards to it directly.
  • The agent’s footprint is a hard constraint. A ceiling that is enforced is a different commitment from a figure that is typical.
  • You want the raw archive in your bucket on day one rather than as a later migration.
  • You want to be able to remove it and have your logging return to exactly what it was, with nothing to unwind.

Edge Delta's documentation was read on 3 September 2026, and every quote above links to the page it came from. Products change, and a comparison page that is not re-read is a slow way of becoming wrong. If something here is out of date or unfair, tell us at [email protected] and we will correct it.

About Auditty

The questions this raises about us.

How much CPU and memory does the Auditty agent use?

In steady state, 60 to 80 MB of memory per node. The agent also ships with an enforced ceiling of 768 MiB and 1.5 vCPU, which it cannot exceed however much log volume you put through it, so the typical figure is what you should expect and the ceiling is what protects you if you are the exception.

That headroom exists for sustained back-pressure, where the worst case we size for is around 420 MB, rather than for normal operation. Consumption is flat with respect to log volume rather than proportional to it, so a tenfold burst in logging does not become a tenfold burst in the agent, and it does not degrade into unbounded growth when a cache or buffer fills.

Both figures are the defaults in the Helm chart, and you can lower them. On a high-pod-density node the guidance goes the other way: raise the ceiling or reduce the event buffer.

Where is my log data stored, and for how long?

Your log data is stored in your own Amazon S3, Google Cloud Storage or Azure Blob Storage bucket, under a prefix you choose, compressed and partitioned by time in an open format your own tools can read. Auditty never holds a copy.

Retention is whatever your own bucket lifecycle policy says, because it is your storage and your billing relationship. Auditty applies no retention limit and takes no storage margin.

Does Auditty replace Datadog, Splunk or my existing SIEM?

No. Auditty sits upstream of your existing log vendor and reduces what reaches it. You keep your dashboards, alerts, queries and runbooks; they simply operate on a stream that no longer contains the repetitive lines nobody reads.

This is deliberate: replacing an observability stack is a multi-quarter migration, while reducing what you send it is a Helm install. Auditty forwards to file destinations, object storage and existing SIEM or log vendors, with no per-connector licensing.

Can I get suppressed logs back later, and how fast?

Yes, in seconds, and without scanning the archive. Every suppression summary links to the raw lines behind it, and following that link returns the actual log lines. The archive is indexed so that a retrieval reads only the small part of it that can contain matches, however large the bucket has become.

You can narrow a retrieval to a single field, such as a latency above a threshold or one specific tenant, and only matching rows are returned. Retrieval also covers the present moment: data too recent to have reached storage is still returned, so there is no blind spot over the last few seconds.

The fastest way to settle this is your own logs.

We will run a sample of them and show you what would have been forwarded, what would have been summarised, and what it would have cost.