OpenTelemetry-native observability for any Python app, from the team behind Pydantic. Auto-instrument FastAPI, Django, SQLAlchemy and httpx one line each, trace your own code, and query all of it with SQL. Free for 10 million spans a month.
pip install 'logfire[fastapi,sqlalchemy,httpx]'import logfire
logfire.configure()
logfire.instrument_fastapi(app) # or logfire.instrument_django()
logfire.instrument_sqlalchemy(engine=engine) # pass your SQLAlchemy engine
logfire.instrument_httpx() # outbound HTTPFrom here, every incoming request opens a trace, and every query and outbound call inside it becomes a child span with timing, attributes, and errors attached. You did not change your business logic.
Every request becomes a trace, the full timeline of one request, built from nested spans, each a timed unit of work like a database query or an outbound call, all with timing and errors attached.
The high-value telemetry comes from the libraries you already use. Each integration is one line: logfire.instrument_fastapi(app), logfire.instrument_django(), logfire.instrument_sqlalchemy(), logfire.instrument_psycopg(), logfire.instrument_httpx(). Every request opens a trace, and every query and outbound call inside it becomes a timed child span. You add instrumentation at the edges and let the request carry the context.
For the code that is actually yours, open a span where a business operation begins with logfire.span("process_order", order_id=order_id), or decorate a function with @logfire.instrument(). Attributes like order_id are queryable, so "every order over $500 that took longer than two seconds" is a real question you can ask.
Most of the Python world validates data with Pydantic, and Logfire is built by the same team. Call logfire.instrument_pydantic() and validation runs show up as spans, with the model, the inputs, and any validation errors captured. When a request fails because a payload did not match your schema, you see exactly which field and why, in production.
Logfire is not just tracing. Send metrics and structured logs alongside your traces, build dashboards, and set alerts, all in the same OpenTelemetry-native project, and query all of it with the same SQL.
Because Logfire speaks OpenTelemetry natively, you are never trapped. Standard opentelemetry-instrument usage and manual OTel spans work unchanged, and you can send the same data to another backend or self-host without touching your instrumentation. Your instrumentation is an asset you own, not rented from a vendor.
select
attributes->>'http.route' as route,
count(*) as requests,
avg(duration) as avg_seconds
from records
where duration > 1
group by route
order by avg_seconds desc;Your traces, metrics, and logs are queryable with real SQL, no proprietary query language to learn. Any question you can express becomes a dashboard, an alert, or a one-off investigation.
| Approach | Strengths | Trade-offs |
|---|---|---|
| Datadog / New Relic | Deep, mature APM | Proprietary agents, pricing that climbs fast at scale |
| Sentry | Excellent error tracking | Tracing and performance are thinner than dedicated APM |
| Standard-library logging | Zero setup, always there | Loose log lines: no timing, nothing connected across a request |
| Raw OpenTelemetry + DIY backend | Fully portable and open | You run and scale the backend yourself |
| Pydantic Logfire | OTel-native, Python-first, SQL queries, hosted | Python and OTel-first, so a weaker fit for non-Python stacks; hosted by default (self-host on enterprise), and younger than the incumbents |
Install an OpenTelemetry-compatible SDK and instrument your libraries. With Pydantic Logfire it is pip install with the extras for the integrations you use, for example pip install 'logfire[fastapi,sqlalchemy]', then logfire.configure(), then one line per library such as logfire.instrument_fastapi(app). Logfire is OpenTelemetry-native, so standard opentelemetry-instrument usage and manual OTel spans also work unchanged.
Logs are individual events. Observability connects them: a trace ties a request to every database query, external call, and function it triggered, with timing and attributes. That is what lets you see why a specific request was slow, rather than scrolling through disconnected log lines.
Auto-instrumentation is designed for production and adds minimal overhead. Telemetry is batched and exported asynchronously, and you can sample traces to control volume. The visibility you gain into slow queries and failing calls typically pays for the small cost many times over.
No. Logfire is built on OpenTelemetry, the open industry standard. Your instrumentation is portable: you can export the same data to another OTel-compatible backend, and the SDK works with standard OpenTelemetry tooling. Logfire adds Python-first ergonomics and SQL querying on top of the open standard.
Yes. Logfire lets you query your traces, metrics, and logs with SQL. Any question you can express in SQL becomes a dashboard, an alert, or an ad-hoc investigation, with no proprietary query language to learn.
Get started with 10 million free spans per month. No credit card required.