Filebeat vs Vector: Routing, transforms, and the better fit for your pipeline

The Filebeat architecture is easy to sketch. It starts inputs, launches a harvester for each discovered file, and sends events through libbeat to the configured output. Elastic lays that out in the Filebeat overview and How Filebeat works. In diagram form, it is:

That narrow scope is an advantage when collection is the only job you want on the node. Filebeat itself is still a self-managed binary or container; the hosted experience, if you buy one, lives in Elastic Cloud rather than in the agent. On Kubernetes, Elastic documents the familiar DaemonSet pattern, mounting /var/log/containers into each pod so every node gets a local collector.

Two lifecycle details matter. The legacy log input is deprecated in 7.16 and disabled by default in 9.0, so current deployments should use filestream. Also, Filebeat modules are still supported, but Elastic recommends Elastic Agent integrations for new work. Filebeat remains viable, but its long-term role inside Elastic is more focused than it once was.

Vector starts from a different model. Its configuration is a graph of sources, transforms, and sinks, not a shipper with one endpoint. The same binary can run on a node as an agent, beside an application as a sidecar, or in a central tier as an aggregator.

That changes the deployment options. You can parse and route at the edge, hand events to another Vector tier for aggregation, or write directly to storage without adding a second routing product. Vector is also self-managed in its open-source form. It accepts YAML, TOML, and JSON, which helps when your config workflow already depends on templating or Kubernetes-native YAML.

The main caution is upgrade discipline. The current release is 0.54.0, and the release notes still recommend stepping through minor versions because the project is pre-1.0.

If your problem is larger than choosing one shipper, NXLog Platform covers a different layer. It combines telemetry collection, log storage, and agent management, which neither Filebeat nor Vector provides by itself.

Filebeat says only a single output may be defined. Vector’s route transform supports splitting one stream into multiple downstream paths. If you need to mirror logs into Kafka and S3 during a migration, or send only selected events to a second backend, Vector can do that in one topology. Filebeat needs another instance or a downstream relay.

Filebeat documents at-least-once delivery and keeps file offsets in the registry. Its reference config shows a memory queue with a default of 3200 events, plus a disk queue that can keep pending events across restarts. The trade-off is familiar: when acknowledgement timing goes badly, duplicates can appear.

Vector exposes more tuning at the component boundary. Its buffering model lets you choose memory or disk buffers and decide whether a full buffer should block upstream components or drop new events. The block and drop_newest behaviors give you a clear choice between preserving older events and keeping the newest data moving. For durability, Vector disk buffers synchronize to disk every 500 ms by default; this favors high throughput but explicitly acknowledges a small window for data loss on system crash.

Vector publishes more concrete sizing advice than Filebeat. Its sizing guide recommends starting around 2 GiB of RAM per vCPU, increasing memory as sink count grows, and sizing disk buffers against expected throughput. Elastic does not publish an equivalent current Filebeat sizing rule in the Filebeat reference docs, so Filebeat capacity work depends more on test-and-measure.

This is not a benchmark, but it is a real workflow difference. Filebeat has a short path to a working Elastic deployment: point it at Elasticsearch and Kibana, then use the documented dashboard loading and ingest pipeline setup. When the output is not Elasticsearch, Elastic says those assets must be loaded manually.

Vector does not ship destination-specific dashboards or ingest assets. You build the pipeline and the destination system handles indexing, dashboards, and alerts.

Neither Filebeat nor Vector is a search product. If you need ad hoc queries, dashboards, or saved investigations, those come from the backend. Filebeat gets you closer to that outcome when the backend is Elastic because the shipper fits neatly into Elasticsearch and Kibana. Vector offers no bundled log search interface. Its built-in observability is aimed at the pipeline itself through internal metrics and pipeline monitoring guidance.

Filebeat gives you a broad processor catalog for metadata enrichment, filtering, field cleanup, and structured parsing. That is enough when edge processing is modest and the heavier parsing belongs in Elasticsearch ingest pipelines.

Vector is stronger when you want the agent itself to own transformation logic. The remap transform uses VRL for parsing, cleanup, and conditional logic. The transform catalog also includes route and exclusive routing, so you can split events by content without adding Logstash or another router.

Neither agent ships with first-class alerting on your log data. Filebeat inherits alerting from Elastic if the data lands there. Vector relies on the destination system, or on alerts built from Vector’s own internal metrics.

The integration story is less even. Filebeat works best when the pipeline already follows Elastic’s model. Vector acts more like neutral plumbing. One useful migration detail is its Logstash source, which can receive traffic from Beats or Logstash senders. That makes it easier to place Vector in front of an existing estate without replacing every sender on day one.