Vector

Collect, transform, and route logs and metrics at scale

4.2(0 reviews)freeFounded 2018United States

free tieropen source

Integrates with

Vector is a high-performance, open source data pipeline for observability data. Collects, transforms, and routes logs, metrics, and traces to any destination. Used as a Fluentd/Logstash alternative.

What Vector actually is

Vector is an open source observability data pipeline: a single Rust binary that collects logs and metrics from dozens of sources, transforms them in flight, and routes them to whatever backends you use. It sits in the monitoring-hosting category less as a host and more as the plumbing between your infrastructure and your observability vendors — the piece that decides what telemetry leaves your machines, in what shape, and at what volume.

The architectural model is a directed graph of sources, transforms, and sinks, declared in TOML, YAML, or JSON. The current stable release (v0.55.0, April 2026) ships 47 sources, 17 transforms, and 61 sinks: kubernetes_logs, journald, file, Kafka, the Datadog Agent protocol, OpenTelemetry OTLP, Prometheus scrape and remote-write on the way in; Datadog, Elasticsearch/OpenSearch, ClickHouse, Grafana Loki, AWS S3 (with Parquet batch encoding as of 0.55), Azure Blob, Kafka, and OTLP forwarders on the way out. A remap transform runs VRL (Vector Remap Language) — a purpose-built, non-Turing-complete expression language for parsing, redacting, and reshaping events — with filter, throttle, reduce, and aggregation transforms around it.

The deployment story is deliberately two-shaped. Run Vector as an agent on every host or pod for collection, or as a centralized aggregator tier that agents ship to (the vector source and sink make chaining instances first-class). Most serious deployments we've seen use both: agents tail local logs, aggregators do the expensive transformation and fan-out once instead of N times. Backpressure, disk buffering, and end-to-end delivery guarantees are configurable per sink, and the project publishes explicit delivery-guarantee labels (best-effort vs. at-least-once) for every component.

Provenance matters here. Vector was born at Timber Technologies (co-founders Zach Sherman and Ben Johnson), with the GitHub repository created in August 2018; Datadog acquired Timber in February 2021 and the project is now maintained by Datadog's Community Open Source Engineering team. It is the open source core behind Datadog's commercial Observability Pipelines product. Adoption is not in dispute: the README claims 100,000+ downloads per day, 500+ contributors, and named users including Atlassian, T-Mobile, Comcast, Discord, Fastly, and Visa — with one deployment processing over 500 TB daily.

Pricing: what you really pay

The software is free. There is no per-node license, no ingest fee, no feature tier, and no usage cap in the open source build — download the binary or container image and run it at any scale. Vector is released under the Mozilla Public License 2.0 (a couple of third-party summaries say Apache-2.0; the GitHub repository is the authority and it says MPL-2.0). Either way, the commercial-use terms are permissive and the code is public.

What you actually pay is operational cost: the CPU and memory Vector consumes on your hosts or aggregator fleet, the engineering time to write and version your pipeline configs, and whatever your destination vendors charge to receive the data. That last item is where Vector earns its keep — its own framing is cost control, and in our view it's the right framing. Sampling, filtering, and aggregating before egress routinely removes more spend than the pipeline costs to run. Teams use it to drop health-check noise, redact PII before it reaches a SaaS backend, and roll high-volume logs up into cheap metrics.

If you want someone else to run the control plane, Datadog sells Observability Pipelines, a managed product built on Vector with monitoring, HA, and support baked in; that pricing is Datadog's standard commercial model and is not cheap, but it is a genuine option for teams standardized on Datadog. The open source tool itself will never send you a bill.

Performance & infrastructure

Vector has no infrastructure of its own — it runs wherever you run it: bare metal, VMs, Kubernetes sidecars, containers, Windows hosts (the 0.55 release added a native windows_event_log source with bookmark-based checkpointing). Data locality is therefore entirely yours: telemetry can be processed inside your network and only the result leaves it, which is the point for compliance teams. Region questions (EU/US/APAC) resolve to "wherever you deploy it."

Performance is the project's founding claim — "up to 10x faster than every alternative in the space" is the vendor's own wording, and we'd treat that as marketing rather than a benchmark. What we can say without inventing numbers: Vector is written in Rust with an async runtime designed around backpressure and adaptive concurrency, it carries a regression test suite and nightly integration/E2E suite in-repo, and users processing hundreds of terabytes per day publicly attest to its throughput. Reliability — not raw speed — is the stated primary design goal, and the codebase shows it: disk buffers for crash recovery, acknowledgements from source to sink where components support them, and per-component guarantee labels so you know exactly which paths can drop data under pressure.

We have not run Vector through our own benchmark rig (see /benchmarks for the VM and hardware numbers we did measure), and we don't quote third-party comparisons as if they were our own. Our editorial position: for pipelines in the 10s of GB/day to multi-TB/day class, Vector's resource footprint has consistently been described by operators as a fraction of Logstash's or Fluentd's for equivalent work, which is the practical reason teams rewrite their pipelines in it.

Where it falls short

Configuration complexity is the tax. Simple pipelines (tail file, parse JSON, ship to one sink) are a dozen lines of TOML; production pipelines with VRL transforms, DLQ handling, multiple aggregators, and per-tenant routing become real software projects that need testing, code review, and staged rollouts. VRL is powerful and fast but it is its own language to learn, and its strict type-checking produces error messages that newcomers find blunt.

The roadmap reflects its owner. Traces support is present (OTLP in and out, Datadog traces sink) but the project's center of gravity is logs and metrics, and the deepest integration work lands on Datadog's stack first. If you are routing to a Datadog competitor, Vector remains vendor-neutral in code — but you are relying on a project staffed by a company that would prefer you use theirs. We don't consider that a deal-breaker (the MPL keeps the code forkable and the community is broad), but it's the kind of trade-off this site exists to state plainly.

Support for the open source build is GitHub issues and community chat — there is no SLA and no guaranteed response. Enterprises that need contractual support must go the Datadog route or self-support. Finally, operational maturity is on you: upgrades are frequent (0.47 in May 2025 to 0.55 in April 2026 — roughly a release a month), occasionally with breaking config changes that need upgrade-guide attention.

Who should pick this

We'd pick Vector whenever telemetry is leaving your control and you want a chokepoint you own: multi-vendor routing, PII redaction before egress, cost reduction via filtering and aggregation, or replacing an aging Logstash/Fluentd estate with one binary and one config language. It is our default recommendation in /category/monitoring-hosting for teams that treat observability data as a supply chain to be managed rather than a stream to be dumped.

We'd skip it for one-host side projects (a vendor agent is simpler) and for teams with zero appetite for operating their own pipeline tier — those teams should either accept the vendor's agent or buy the managed product.

The pragmatic setup we'd suggest: start as a single agent on one host, prove the parsing and routing config in version control, then promote to an agent-plus-aggregator topology once volumes justify centralizing transforms. Keep VRL transforms unit-tested; Vector's vector test runner exists for exactly this.

Key takeaways

Open source (MPL-2.0) Rust pipeline: 47 sources, 17 transforms, 61 sinks as of v0.55.0 (April 2026), configured in TOML/YAML/JSON.
Free at any scale — no license, no ingest fee; you pay only to run it and to receive data at the far end.
Born at Timber (2018), acquired by Datadog (2021), maintained by Datadog's Community Open Source Engineering team; powers Datadog Observability Pipelines.
Strong fit for pre-egress control: redaction, sampling, fan-out to multiple vendors from one pipeline. It is the piece we would put between agents and vendors when log volume is high and contracts require redaction before data leaves the building.
No SLA or enterprise support in the open source build; VRL and pipeline config carry real learning and upkeep cost.
Our view: the strongest free option for owning your observability data path — buy the managed variant only when you need contracts, not capability.

Sources

Pros

Free at any scale: no license fees, no ingest caps, no feature tiers
One binary for the whole pipeline: 47 sources, 17 transforms, 61 sinks
Pre-egress control plane — redact, sample, aggregate, and fan out before data leaves your network
Rust reliability engineering: disk buffers, acknowledgements, per-component delivery guarantees
Battle-tested at scale (public users at 500+ TB/day) with active Datadog-backed maintenance

Cons

VRL and pipeline configuration are a real learning investment; advanced pipelines become software projects
Open source support is community-only — no SLA, no guaranteed response
Roadmap gravity favors Datadog's ecosystem; deepest integrations land there first
Frequent releases with occasional breaking config changes require planned upgrades
Traces support exists but is less mature than the logs and metrics paths

Best For

DevOps and platform teams that want to own their observability data path — controlling cost, redaction, and multi-vendor routing before telemetry leaves their infrastructure