Vector (vectordotdev/vector): a Rust observability pipeline you configure in YAML

What Vector solves, and who ends up running it

Most teams do not choose their collector. It arrives with the vendor, reads a fixed set of files, and forwards to one endpoint. Vector targets the moment that stops working: two vendors, three log formats, a compliance rule that says certain fields must not leave a region, and a bill that grows with volume rather than value. Vector's README frames the product as an end-to-end pipeline that lets you "Collect, transform, and route all your logs and metrics to any vendors you want today and any other vendors you may want tomorrow." The intended reader is a platform or observability engineer who owns the telemetry path and wants the routing decision to be a config file rather than a vendor's roadmap.

The repository describes two deployment roles, agent and aggregator. An agent runs next to the workload and reads local files or sockets; an aggregator receives from many agents and fans out to destinations. That split matters because it is also the split in operational burden. One agent per host is a package problem. An aggregator tier is a service you now page someone about. Vector's own use-case list includes "consolidate agents and eliminate agent fatigue," which is honest about the starting condition: most adopters arrive with several collectors already installed.

Sources, transforms, sinks: the actual data flow

The architecture is a directed graph declared in a config file. A source produces events, zero or more transforms reshape them, and sinks write them out. Event types are logs and metrics, with traces listed as coming soon in the README, so a team expecting a single pipeline for all three signals should treat traces as not yet available here. The README also marks metrics as beta, which is a signal to check the specific metric source and sink you need rather than assuming parity with logs.

Because the graph is declared rather than coded, the interesting work moves into config review. A transform that drops a field is a one-line diff, and so is a sink that starts sending production logs to a staging bucket. Vector ships a validation step for this reason: the binary can check a config without starting the pipeline, which is the cheapest place to catch a typo in a component name. The README points to a components page for the full list of integrations rather than enumerating them, so the practical first task on any evaluation is to confirm that your source and your sink both exist and are not marked beta.

Reliability is stated as the primary design goal, and the repository backs that with a correctness comparison table covering cases like disk buffer persistence and file rotation under both create and copytruncate. Those are the failure modes that produce silent data loss in collectors, and they are worth reading before you trust a default. The same README table shows Vector losing the regex parsing case to FluentBit, 13.2mib/s against 20.5mib/s, so heavy regex work is not where this project's numbers are strongest.

Installing Vector and running a first pipeline

The README does not inline install commands. It links to a quickstart guide and an installation page, and it links a download endpoint and container images on GitHub Packages. Those are the two supported starting points: a release binary or the container image. The Debian packaging metadata in Cargo.toml shows what the package installs, including a systemd unit at /lib/systemd/system/vector.service, a default file at /etc/default/vector, and an example config at /usr/share/vector/examples/vector.yaml. If you install from a package, that example file is the fastest thing to copy.

Config can be written in YAML, and the repository ships config/vector.yaml as a top-level example. The Debian package metadata also installs config/examples/* into /etc/vector/examples/, which is the directory to read for working component configurations rather than inventing keys. The repository's top-level config/ directory is the source of those files, and the components documentation linked from the README is where each source, transform and sink type is described.

A config is a map of sources, transforms and sinks, each entry naming a component, giving it a type, and wiring it to its inputs. Before starting the pipeline, check the file with the binary's config validation subcommand so that a mistyped component name or field surfaces immediately instead of at startup under load. The example config shipped in the repository is the reference to copy from; the README does not print one inline.

For a container-based try, the image is published on GitHub Packages as ghcr.io/vectordotdev/vector. Mount your config and your log directory, and run the same binary with the config path as an argument. The repository's Tiltfile and tilt/ directory exist for local development of Vector itself, not for running a pipeline, so do not reach for them as a deployment path.

Where Vector is the wrong tool

The clearest limitation is that Vector is a pipeline, not a storage or query layer. It routes and reshapes events; it does not index them, and nothing in the README suggests otherwise. Teams that pick it hoping to replace a logging backend will end up running a backend plus Vector.

Second, the config surface is large. Every source, transform and sink has its own keys, and the README defers the details to the components documentation. That is fine for a platform team and painful for a small team that wants one file shipped to one vendor. The README's own comparison table is a useful reality check here: SplunkUF edges out Vector on TCP to TCP at 70.4mib/s against 69.9mib/s, and FluentBit wins regex parsing outright. Vector's headline wins are in file-to-TCP and TCP-to-HTTP throughput, not across every case.

Third, the operational surface is real. An aggregator tier means capacity planning, buffer sizing and a new thing that can drop data. The README does not document rollback for a bad config push, and the repository's RELEASES.md and VERSIONING.md are the places to read before you decide how aggressively to track new versions. A team with no one on call for the telemetry path should think hard before inserting a self-managed hop between their applications and their vendor.

Vector against Fluent Bit, Fluentd and Logstash

The obvious alternatives are the other collectors in the README's own comparison tables. Fluent Bit is the closest in spirit: a small forwarder written in C, and the table shows it ahead of Vector on regex parsing while trailing on file-to-TCP throughput. The difference in approach is breadth against weight. Fluent Bit aims to be a light forwarder; Vector aims to be both the agent and the aggregator, with a single config language and a stated goal of unifying logs and metrics. If your problem is one host shipping files to one endpoint, Fluent Bit's smaller footprint is a legitimate reason to pick it.

Fluentd and Logstash are the older, plugin-heavy generation. Logstash's numbers in the same tables are far lower on file-to-TCP, and Fluentd's are lower still, though raw throughput is not the only axis and both have mature plugin ecosystems. The real difference is the runtime: Vector is Rust with a single static binary and no JVM or Ruby runtime to install, which simplifies packaging and removes a class of memory-tuning work. SplunkUF and SplunkHF are the comparison points if you are already a Splunk shop, and the table shows them competitive on TCP to TCP. Choosing Vector there is a bet on portability over vendor alignment.

Licence, maintenance and what an upgrade costs

Vector is MPL-2.0, a file-level copyleft licence. Modifying Vector's own source files and distributing them carries obligations; embedding the unmodified binary in your stack does not change the licence of your application. That is the general shape of MPL, not legal advice, and any organisation with a policy on copyleft should run the specifics past its own counsel. The repository also ships LICENSE-3rdparty.csv and a licenses/ directory, which is where to look for the dependency licences that come along with the binary.

Maintenance is not in question on the evidence available. The last push was on 2026-09-10, and the release history shows v0.58.0 on 2026-08-26 alongside frequent vdev-v0.3.x releases. The project is not archived, and it is maintained by Datadog's Community Open Source Engineering team. Note the version split: the Cargo.toml in the repository declares version 0.59.0 while the latest tagged release listed is v0.58.0, so master runs ahead of the last release. The vdev-v0.3.x tags are a separate, faster-moving tool in the vdev/ directory, not Vector itself.

The upgrade cost is mostly config compatibility. The repository keeps a deprecation.d/ directory and a VERSIONING.md policy, which is the mechanism to check before bumping a version: a deprecated component name or removed key is the kind of change that turns a routine upgrade into an outage. The release profile in Cargo.toml uses fat LTO and a single codegen unit, so building from source is slow, and rust-version is 1.95. Most teams should take the release binary or the container image rather than compile it.

Editorial conclusion

Adopt Vector if you need to route logs and metrics between systems you control and are willing to run and monitor the pipeline yourself. Do not adopt it if you want a managed collector with a support contract, or if your only requirement is shipping one file to one vendor, since a vendor agent will be less work. Before committing, verify three things against your own data: that the source you need handles your file rotation or truncation pattern, that your chosen sink's delivery guarantees match what you can lose, and that the disk buffer directory has room and the right permissions, because the README does not document rollback for a bad config push.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. vectordotdev/vector on GitHub