Loki vs Vector for Log Shipping

Promtail Was Fine Until It Wasn’t

Promtail wins if Loki is your only destination and your logs are already simple, and Vector wins the moment you need multiple destinations, in-agent transforms, or redaction.

You’ve got logs flooding in from containers, servers, and applications. You set up Promtail, Grafana’s purpose-built agent for Loki, and it’s been humming along fine for months. Dead simple. Scrape logs, attach labels, ship to Loki. Done.

Then someone asks: “Why are we not archiving cold logs to S3?” Or: “Can we forward these security events to a separate system?” Or worse: “The overhead on that edge node is killing us; we need filtering.”

And you realize Promtail isn’t really designed for that. It’s the specialized pickup truck for one job: grab logs, label ‘em, send to Loki. Which is great until you need the pickup truck to also carry building materials and tow a trailer.

Enter Vector. Datadog’s open-source observability agent: the Swiss Army knife of log shipping. It transforms logs, fans them out to multiple sinks, filters, samples, and does it all in a single binary with zero runtime overhead.

Vector isn’t Loki’s replacement. It’s Promtail’s replacement, the agent that ships logs to Loki. The confusion is real, and it matters for your architecture.

Which Log Shipper Should You Actually Deploy?

What’s a Log Shipper, Really?

Before we get into the face-off, let’s nail what these tools actually do.

A log shipping agent sits on your servers or in your containers. Its job is:

1. Scrape logs from files, journald, syslog, containers, wherever
2. Parse unstructured blobs into structured data (if you’re smart about it)
3. Enrich with metadata: hostnames, service names, environment labels
4. Transform if needed: redact secrets, drop spam, sample high-volume streams
5. Ship to a backend: Loki, S3, Datadog, Splunk, Kafka, wherever

Promtail does 1, 3, and 5 beautifully. It’s laser-focused. Vector does all five and then some.

Promtail: The Specialist Tool

Promtail is Grafana’s agent for Loki. Built for one job. Here’s what it brings:

The Good

• Dead simple: YAML config, no learning curve if you know Prometheus scrape syntax. Relabeling is familiar.
• Lightweight: ~30 MB binary, minimal memory. Runs on Raspberry Pis and edge nodes without flinching.
• Label-native: Loki thinks in labels, not full-text search. Promtail was built for that mindset. Attach labels at scrape time, query by labels in LogQL.
• Prometheus integration: Works like a Prometheus target. Same scrape intervals, same sd_configs for service discovery.

The Problem

Here’s where the honest truth gets uncomfortable: Promtail is dead. It hit end-of-life on March 2, 2026: no more security patches, no more bug fixes, nothing. Grafana moved everyone to Alloy, their unified telemetry collector (logs, metrics, traces, profiles, all in one). Promtail’s binary still runs, but you’re running unpatched software now, and that’s a different risk calculation than “maintenance mode.”

If you’re starting fresh, Alloy is the play (Grafana ships a convert command to translate your old Promtail config). But Alloy is heavier, more complex, and if you only need logs, you’re paying for features you won’t touch.

Real talk: Promtail’s biggest limitation is inflexibility. You’re limited to what it can do out of the box. Parsing complex JSON logs? You can do it, but it’s clunky. Redacting sensitive data? There’s no built-in secret-scrubber. Sampling to reduce cardinality? Nope. Multi-destination shipping? Absolutely not.

Vector: The Flexible Heavy

Vector is Datadog’s open-source Swiss Army knife. It’s not built for Loki, it’s built to ship logs (and metrics, and traces) to anywhere.

The Good

• Transforms: VRL (Vector Remap Language) lets you parse, enrich, redact, and restructure logs in a declarative language. Feels like Jq for observability.
• Multiple sinks: Ship to Loki, S3, Kafka, Datadog, Splunk, syslog, HTTP webhooks, simultaneously. One agent, many destinations. Hot path to Loki, cold path to S3. Done.
• Built-in sampling and filtering: Drop events by condition, sample high-volume sources, buffer intelligently.
• Metrics + traces: One binary can do logs, host metrics, and distributed traces. Unified config.
• VRL for redaction: Mask credit cards, API keys, passwords before they hit your storage. GDPR compliance without extra tooling.
• No vendor lock-in: Datadog open-sourced it. It works everywhere, on prem or cloud.

The Catch

• More complex: Config is more expressive, which means more things to get wrong. YAML+VRL can feel like learning a new language.
• Heavier footprint: ~50-100 MB binary, more memory. Still light compared to log shippers from five years ago, but heavier than Promtail.
• Learning curve: VRL is powerful but not intuitive if you’ve never written a domain-specific language. Your oncall team will need training.
• Not Loki-native: Vector doesn’t understand Loki’s label philosophy. It’ll ship logs fine, but you’re encoding labels as part of the Loki sink config, not as first-class citizens in the agent.

The Real Showdown: When Do You Pick Each?

Pick Promtail if:

• You’re using Loki and only Loki for logs. No S3 archive, no forwarding to a SIEM, no multi-destination shenanigans.
• Your logs are already structured (JSON) or simple key=value. You’re not doing complex parsing.
• You need the absolute minimum footprint: Raspberry Pi in your home lab, containerized edge nodes.
• Your team is already comfortable with Prometheus-style configs. Reusing that knowledge matters.
• You can live with running EOL software: Promtail still ships logs fine, but nobody’s patching it anymore, so weigh that.

Pick Vector if:

• You need to ship logs to multiple places simultaneously. Cold tier to S3, hot tier to Loki.
• You’re doing significant log transformation: parsing, redaction, sampling, enrichment in-agent.
• You need VRL for conditional logic or regex work that Promtail can’t handle.
• You’re in a multi-backend world and don’t want tool sprawl. One agent for logs, metrics, and traces.
• You’re comfortable with a slightly heavier footprint and training your team on VRL.

A Concrete Example: Loki + Vector

Here’s what a minimal Vector config looks like shipping to Loki:

sources:
  docker_logs:
    type: docker_logs

transforms:
  parse_json:
    type: remap
    inputs: [docker_logs]
    source: |
      . = parse_json!(.message)
      if exists(.password) {
        .password = redact(string!(.password), filters: [r'\S+'])
      }

sinks:
  loki_hot:
    type: loki
    inputs: [parse_json]
    endpoint: "http://loki:3100"
    encoding:
      codec: json
    labels:
      service: "{{ service }}"
      environment: "production"

  s3_archive:
    type: aws_s3
    inputs: [parse_json]
    bucket: "logs-archive"
    key_prefix: "logs/{{ year }}/{{ month }}/{{ day }}/"
    compression: gzip
    encoding:
      codec: json

One Vector binary. Two sinks. JSON parsing, redaction, and labeling, all declarative. Loki gets hot logs. S3 gets the archive. Done in about 30 lines.

Compare that to Promtail: you can’t do the S3 piece. You’d need a separate tool (Fluent Bit, Filebeat, rsyslog) for the archive path. Suddenly you’re managing two agents and two configs.

The Label Cardinality Trap (Applies to Both)

Here’s where both agents can burn you: unbounded label cardinality.

Loki stores logs indexed by labels. If you attach a unique label value on every log (like a request ID or timestamp), you’ve created a cardinality explosion. Loki will either OOM or become unusable.

# BAD — don't do this
relabel_configs:
  - source_labels: [__docker_label_request_id]
    target_label: request_id

If request_id is unique per log, you’ve wrecked yourself.

Both Promtail and Vector let you shoot yourself in the foot here. The fix is the same: be disciplined about labels. Attach labels for dimensions you’ll actually query by, like service, environment, version, region. Don’t attach event-level cardinality. That’s what the log body is for.

Vector’s VRL makes this easier to control explicitly:

.service = "my-app"
.env = "prod"
del(.request_id)  # drop the high-cardinality field before it becomes a label

Promtail forces you into Prometheus relabeling, which is more implicit.

Fluent Bit: The Third Player (Briefly)

One mention: Fluent Bit is another option. It’s lightweight, mature, and widely used. But it’s not Loki-native, and its output plugin ecosystem is more fragmented. If you’re doing multi-destination shipping, Vector’s VRL + unified config is cleaner. If you’re purely Loki and want something between Promtail and Vector, Fluent Bit works, but Vector’s overhead is worth the flexibility.

Performance and Resource Reality

In production, here’s what matters:

• Promtail: 20-30 MB memory, minimal CPU. Negligible overhead on any node.
• Vector: 50-150 MB memory depending on buffer depth, slightly more CPU for VRL processing. Still negligible on modern infrastructure.

If you’re scraping gigabytes of logs per second, Vector’s transform logic adds maybe 5% overhead. Not a blocker.

The real question isn’t resource usage, it’s operational complexity. More config means more bugs. More tooling means more to maintain.

Alloy: The Future (If You’re Starting Now)

If you’re planning a greenfield observability stack, Alloy is worth serious consideration. It’s Grafana’s unified telemetry collector, handling logs, metrics, traces, profiles, all in one. It’s meant to replace Promtail, Grafana Agent, and eventually more.

But Alloy is newer, has a smaller community, and is heavier than Promtail. Unless you’re already using Grafana for metrics and traces, it’s overkill.

For pure log shipping in 2026? Vector or Promtail, and that choice depends on your architecture, not on Alloy.

Pick the Shipper That Survives Your Workload

Here’s my honest take:

Promtail still works if you’re using Loki and your logs are simple. It’s lightweight and it ships logs reliably. But it’s officially EOL as of March 2026 with no patches coming, so for anything new I’d reach for Alloy instead. Promtail is now a “keep it running if it’s already running” tool, not a “deploy it fresh” one.

Vector is the play if you need flexibility. Multi-destination shipping, complex transforms, VRL-based redaction: Vector handles all of it in one agent. Yes, it’s heavier and more complex. But if you’re doing observability at any real scale, you’re probably doing all three anyway.

The mistake I see most: picking the wrong tool for the wrong reasons. Don’t pick Promtail because “it’s simpler” if you actually need transforms. Don’t pick Vector because “it’s fancy” if you’re going to run Loki and nothing else.

Know your requirements. Make the call. Move on.

Your future self, the one debugging a log shipping bottleneck at 2 AM, will appreciate the clarity.

Related Reading

• Vector vs Fluent Bit: Modern Log Shippers
• ClickHouse for Self-Hosted Logs
• Alertmanager Routing Trees That Don’t Lie
• Blackbox Exporter: HTTP/TCP/DNS/ICMP Probes
• cAdvisor + Prometheus: Per-Container Metrics Done Right