Pydantic Logfire Review (2026)

The pricing is the story

Most observability pricing sections are a table you skim. This one is the reason to read the page.

Logfire gives you 10 million records a month free, then charges $2 per million. There is no metering on seats, hosts or projects. You pay for what you send, and nothing else.

Plan	Price	Seats	Projects	Retention
Personal	$0	1	3	30 days
Team	$49/mo	5	5	30 days
Growth	$249/mo	Unlimited	Unlimited	Extended
Enterprise	Custom	Custom	Custom	Custom, self-host, SSO

Pydantic restructured pricing effective 1 January 2026. The important thing about that restructure is what did not change: the free tier stayed at 10 million records and the overage rate stayed at $2 per million. The restructure added clearer tiers rather than raising prices, which is the opposite of what usually happens in this category.

Set that against the alternatives. Datadog charges per LLM span with a 40,000-span free tier. LangSmith charges per seat. W&B Weave charges per GB ingested. Logfire’s free allowance alone is two orders of magnitude larger than Datadog’s, and its paid rate is a flat, forecastable number.

The trap: metrics are records

Here is the thing that catches people, and it is not in the headline pricing.

Logfire bills on records, and records means spans plus logs plus metrics. Not just LLM spans. Everything.

That matters because common integrations emit aggregate metrics under the hood without being asked. httpx, SQLAlchemy and FastAPI all do this. Each emitted metric counts as one record, regardless of how many underlying requests it summarises.

The consequence is that your record count can be substantially higher than your span count, and the difference is invisible until you look at a bill. A team instrumenting a FastAPI service with a SQLAlchemy backend and httpx calls out to an LLM provider is emitting three streams of automatic metrics alongside the traces they actually wanted.

The mitigation is simple and you should do it on day one: disable auto-emitted metrics you are not using. The commonly cited cost-saving tactic in the Logfire community is exactly this. Do it before you model your costs, because a naive spans-only estimate will be wrong.

The second, smaller gotcha: there is a 5 KB average payload budget per span or metric. Payload size is averaged over time, so occasional large spans are fine, but a RAG application routinely logging big retrieved-context blocks should check this rather than assume.

The free tier hard-caps, and that is a feature

This deserves its own section because almost nobody else does it.

When you hit the limit on the Personal tier, ingestion pauses. You do not get billed for overage. You cannot owe anything.

Every engineer who has run production observability has a story about a retry loop, a debug log left at trace level, or a runaway agent that generated a five-figure invoice overnight. The standard industry design lets that happen and sends you the bill. Logfire’s default is to stop.

On paid tiers the same protection is available - you can contact them to set a hard price cap, and when you hit it ingestion pauses so the bill never exceeds what you approved.

For a category where surprise bills are the single most common complaint, this is a genuinely differentiated design decision and we weight it heavily.

Full-stack, not an LLM silo

Logfire is built on OpenTelemetry and instruments your whole application, not just the model calls.

That sounds like a minor architectural note. In practice it changes what you can debug. When an agent request takes eleven seconds, the question is where - the model, the vector search, a slow SQL query, or an upstream API. An LLM-only tool shows you the model span and an unexplained gap. Logfire shows you the SQLAlchemy query inside the same trace.

Two further capabilities are worth calling out because they are unusual:

SQL over your telemetry. Data is queryable via a PostgreSQL-compatible interface. When you know what you are looking for, writing a query beats clicking through a filter UI, and it means your telemetry is accessible to any tool that speaks Postgres.

An MCP server. Logfire exposes your traces to AI coding agents through MCP. An agent debugging a failure can read the actual production trace rather than being told about it. This is a genuinely novel capability in the category and, given where development workflows are heading, a reasonable thing to weight.

The platform also bundles Pydantic AI Gateway for multi-provider routing, cost limits and failover, which overlaps with what you would otherwise buy from Portkey or LiteLLM.

Where it is weaker

Retention. Thirty days below Growth. Fine for debugging, insufficient for quarter-over-quarter quality tracking or compliance retention. This is the constraint most likely to push a serious team from $49 to $249.

Self-hosting is Enterprise-only. Langfuse, Phoenix and Opik all self-host for free. If policy requires your traces stay in your infrastructure, Logfire’s cost advantage is unavailable to you at the tiers where it matters.

Evals. Pydantic Evals is capable and integrates properly, but it is younger and less turnkey than Braintrust for dataset-driven regression testing. If release-gating evals are your primary requirement rather than observability, pair it with something or look elsewhere.

Should you use it?

Use Logfire if you want one observability tool for your entire application, you are on OpenTelemetry or willing to be, and predictable low cost matters. It is close to an automatic choice for Python shops already using Pydantic or Pydantic AI.

Don’t use it if you need self-hosting below Enterprise, you need retention beyond 30 days on a small budget, or evals rather than tracing are the actual requirement.

Bottom line: the strongest price-to-capability ratio in the category, with a hard-cap design that protects you from the failure mode that makes observability bills scary. Turn off the auto-emitted metrics you do not need before you estimate anything, budget for Growth if you need real retention, and it is very hard to beat.

---

Pricing verified against the vendor’s published rate card following the 1 January 2026 restructure, on 31 July 2026. Competitive cost multipliers cited by the vendor are flagged as unverified. This is a researched directory entry - we have not yet instrumented this platform with our reference application.