OpenTelemetry-native observability for Django, from the team behind Pydantic. See every request, view, and ORM query as one trace, so N+1 queries and slow endpoints jump out in production, not just in the Debug Toolbar. Free for 10 million spans a month.
pip install 'logfire[django,psycopg]'# settings.py, at the very end, after your other settings
import logfire
logfire.configure()
logfire.instrument_psycopg() # use the integration that matches DATABASES
logfire.instrument_django() # keep this lastPut this at the end of settings.py, after the rest of your settings, with instrument_django() last so it wraps the fully-configured app and no request slips through uninstrumented. Swap instrument_psycopg() for the integration that matches your DATABASES engine.
Every request becomes a trace, the full timeline of one request, built from nested spans, each a timed unit of work, for the view and each ORM query. So an N+1, where the code runs one extra query per row instead of one for all of them, shows up as the same query firing thirty times in one trace, impossible to miss.
This is where tracing earns its keep for Django. When your ORM query span shows up thirty times inside a single request, each nearly identical, you have found an N+1, and you have found it against real traffic rather than a synthetic local page. The trace shows the problem and confirms the fix once you add select_related or prefetch_related.
Add the layers a Django app leans on, one line each: logfire.instrument_django(), logfire.instrument_psycopg(), logfire.instrument_requests(), logfire.instrument_celery(), logfire.instrument_redis(). Call logfire.instrument_celery() in the Celery worker process too, not just the web process, so a task kicked off by a request stays connected to the trace that started it and a slow background job is a single readable story.
For business operations, open a span where the work begins with logfire.span("checkout", cart_id=cart.id). It becomes the parent of the auto-instrumented queries and calls it triggers, with attributes you can filter and group on.
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.
Logfire is OpenTelemetry underneath. Standard OpenTelemetry tooling works, and you can export the same telemetry to another backend or self-host without touching your app. You instrument once against the open standard.
select
attributes->>'db.statement' as query,
count(*) as calls,
sum(duration) as total_seconds
from records
where attributes->>'db.system' = 'postgresql'
group by query
order by total_seconds desc;Your traces, metrics, and logs are queryable with real SQL, no proprietary query language to learn. Django developers can investigate production from the first minute.
| Approach | Strengths | Trade-offs |
|---|---|---|
| Django Debug Toolbar | Ideal in local development | Development only, no production view |
| Datadog / New Relic | Deep APM | Proprietary agents, pricing climbs at scale |
| Sentry | Strong error tracking | Lighter on tracing and query-level detail |
| Raw OpenTelemetry + DIY backend | Portable and open | You run the backend yourself |
| Pydantic Logfire | One-line Django setup, query-level tracing, SQL, hosted | Python and OTel-first, so a weaker fit for non-Python stacks; hosted by default, and younger than the incumbents |
Install Pydantic Logfire, call logfire.configure() early in your entry point, then logfire.instrument_django() to trace requests and the integration that matches your database driver, such as logfire.instrument_psycopg() or logfire.instrument_sqlite3(), to trace ORM queries. Logfire is OpenTelemetry-native, so standard OpenTelemetry tooling works as well.
Yes, and it is one of the biggest wins. With database instrumentation enabled, a repeated ORM query shows up as many nearly identical spans inside one request trace. That makes N+1 patterns obvious against real production traffic, and the trace confirms the fix once you add select_related or prefetch_related.
Yes. The Django Debug Toolbar is excellent for local development but runs only there. Logfire gives you the same query-level and timing detail in production, across real requests, background tasks, and external calls, with alerting and history.
Auto-instrumentation is designed for production use. Telemetry is batched and exported asynchronously, and traces can be sampled to control volume, so overhead is small compared to the time saved finding slow queries and failing requests.
Get started with 10 million free spans per month. No credit card required.