---
title: "Introducing Pydantic Logfire: What sets Logfire apart"
description: "Logfire unifies metrics, tracing, and structured data logging into one simple platform. End-to-end general and AI observability powered by Pydantic."
---
# Introducing Pydantic Logfire

From the team behind Pydantic Validation, **Pydantic Logfire** is an observability platform built on the same belief as our open-source library: that a tool can be genuinely capable and still be quick to pick up.

## What sets Logfire apart

<div class="grid cards" markdown>

- :rocket:{ .lg .middle } **Simple to use, deep when you need it**

  ***

  Logfire is approachable enough that your whole engineering team will actually use it, and you'll see your first data within about five minutes.

  [:octicons-arrow-right-24: Read more](#simplicity-and-power)

- :material-robot-outline:{ .lg .middle } **The full AI engineering loop**

  ***

  Beyond tracing every LLM call with token and cost tracking, Logfire ships **evals** (in the web UI and in code), **prompt management** with a playground, and an **AI gateway** with key management and spending controls: one platform from prototype to production.

  [:octicons-arrow-right-24: Read more](ai-observability.md)

- :material-code-braces:{ .lg .middle } **Deep language integration**

  ***

  Python has the deepest integration (rich display of **Python objects**, **event-loop telemetry**, and **profiling**), but Logfire also has native SDKs for **JavaScript/TypeScript** and **Rust**, and works with **any OpenTelemetry language**.

  [:octicons-arrow-right-24: Read more](#deep-language-integration)

- :simple-pydantic:{ .lg .middle } **Pydantic integration**

  ***

  Understand the data flowing through your Pydantic Validation models and get built-in analytics on validations. Pydantic Logfire helps you instrument your applications with less code, less time, and better understanding.

  [:octicons-arrow-right-24: Read more](#pydantic-integration)

- :telescope:{ .lg .middle } **OpenTelemetry**

  ***

  Logfire is an opinionated wrapper around OpenTelemetry, allowing you to use existing tooling, infrastructure, and instrumentation for many common Python packages, and enabling support for virtually any language.

  [:octicons-arrow-right-24: Read more](#opentelemetry-under-the-hood)

- :simple-instructure:{ .lg .middle } **Structured data**

  ***

  Include your structured data in Logfire calls (in Python, that means lists, dicts, dataclasses, Pydantic models, DataFrames, and more) and it'll end up as structured data in our platform ready to be queried.

  [:octicons-arrow-right-24: Read more](#sql)

- :abacus:{ .lg .middle } **SQL**

  ***

  Query your data using standard SQL: all the control and (for many) nothing new to learn. Using SQL also means you can query your data with existing BI tools and database querying libraries.

  [:octicons-arrow-right-24: Read more](#sql)

</div>

## Find the needle in a _stack trace_

Pydantic Logfire was built by developers who understand real applications: from async Python services to JavaScript frontends to multi-language distributed systems. With deep integrations across Python, JavaScript/TypeScript, Rust, and any OpenTelemetry-compatible language, it's about having the _right_ data, presented in ways that make sense for your applications.

![Logfire FastAPI screenshot](images/index/logfire-screenshot-fastapi-200.png)

## Simple to use, deep when you need it {#simplicity-and-power}

Emulating the Pydantic library's philosophy, Pydantic Logfire offers an
intuitive start for beginners while providing the depth experts desire. It's the same balance of ease, sophistication,
and productivity, reimagined for observability.

Within a few minutes you'll have your first logs:

![Logfire hello world screenshot](images/index/logfire-screenshot-hello-world-age.png)

This might look like ordinary logging, but it does much more. You get:

- **Structured data** from your logs
- **Nested logs &amp; traces** to contextualize what you're viewing
- **Custom-built platform** to view your data, with no configuration required
- **Pretty display** of Python objects

Ready to try Logfire? [Get Started](index.md)!

## Deep language integration {#deep-language-integration}

**Pydantic Logfire** automatically instruments your code for minimal manual effort, gives you clear
visibility into async code, offers detailed performance analytics, and displays Python
objects the same as the interpreter. Python has the deepest integration, but Logfire also has native SDKs for JavaScript/TypeScript and Rust, and works with any OpenTelemetry-compatible language.

### Rich display of Python objects

![Logfire FastAPI screenshot](images/logfire-screenshot-fastapi-arguments.png)

In this example, you can see the parameters passed to a FastAPI endpoint formatted as a Python object.

### Profiling Python code

![Logfire Auto-tracing screenshot](images/logfire-screenshot-autotracing.png)

In this simple app example, you can see every interaction the user makes with the web app automatically traced to the Live view using the [Auto-tracing method](guides/onboarding-checklist/add-auto-tracing.md).

## Pydantic integration

**Logfire** has a built-in **Pydantic** integration that lets you understand the data
passing through your Pydantic models and get analytics on validations. For existing Pydantic users,
it shows you exactly how your Pydantic models are being used.

We can record Pydantic models directly:

```py
from datetime import date

from pydantic import BaseModel

import logfire

logfire.configure()


class User(BaseModel):
    name: str
    country_code: str
    dob: date


user = User(name='Anne', country_code='USA', dob='2000-01-01')
logfire.info('user processed: {user!r}', user=user)  # (1)!
```

1. This will show `user processed: User(name='Anne', country_code='USA', dob=datetime.date(2000, 1, 1))`, but also allow you to see a "pretty" view of the model within the Logfire Platform.

![Logfire pydantic manual screenshot](images/index/logfire-screenshot-pydantic-manual.png)

Or we can record information about validations automatically:

```py skip-run="true" skip-reason="global-instrumentation"
from datetime import date

from pydantic import BaseModel

import logfire

logfire.configure()
logfire.instrument_pydantic()  # (1)!


class User(BaseModel):
    name: str
    country_code: str
    dob: date


User(name='Anne', country_code='USA', dob='2000-01-01')  # (2)!
User(name='Ben', country_code='USA', dob='2000-02-02')
User(name='Charlie', country_code='GBR', dob='1990-03-03')
```

1. This configuration means details about all Pydantic model validations will be recorded. You can also record details about validation failures only, or just metrics; see the [pydantic plugin docs](integrations/pydantic.md).
2. Since we've enabled the Pydantic Plugin, all Pydantic validations will be recorded in Logfire.

Learn more about the [Pydantic Plugin here](integrations/pydantic.md).

![Logfire pydantic plugin screenshot](images/index/logfire-screenshot-pydantic-plugin.png)

## OpenTelemetry under the hood {#opentelemetry-under-the-hood}

Because **Pydantic Logfire** is built on [OpenTelemetry](https://opentelemetry.io/), you can
use a wealth of existing tooling and infrastructure, including
[instrumentation for many common Python packages](https://opentelemetry-python-contrib.readthedocs.io/en/latest/index.html). Logfire also supports cross-language data integration and data export to any OpenTelemetry-compatible backend or proxy.

For example, we can instrument a simple FastAPI app with just 2 lines of code:

```py title="main.py" hl_lines="10-11" skip-run="true" skip-reason="global-instrumentation"
from datetime import date

from fastapi import FastAPI
from pydantic import BaseModel

import logfire

app = FastAPI()

logfire.configure()
logfire.instrument_fastapi(app)  # (1)!
# Here you'd instrument any other library that you use. (2)


class User(BaseModel):
    name: str
    country_code: str
    dob: date


@app.post('/')
async def add_user(user: User):
    # we would store the user here
    return {'message': f'{user.name} added'}
```

1. In addition to [configuring logfire](reference/configuration.md) this line is all you need to instrument a FastAPI app with Logfire. The same applies to most other popular Python web frameworks.
2. The [integrations](integrations/index.md) page has more information on how to instrument other parts of your app. Run the [inspect](reference/cli.md#inspect-inspect) command for package suggestions.

We'll need the [FastAPI contrib package](integrations/web-frameworks/fastapi.md), FastAPI itself and uvicorn installed to run this:

```bash
pip install 'logfire[fastapi]' fastapi uvicorn  # (1)!
uvicorn main:app # (2)!
```

1. Install the `logfire` package with the `fastapi` extra, FastAPI, and uvicorn.
2. Run the FastAPI app with uvicorn.

This will give you information on the HTTP request and details of results from successful input validations:

![Logfire FastAPI 200 response screenshot](images/index/logfire-screenshot-fastapi-200.png)

And, importantly, details of failed input validations:

![Logfire FastAPI 422 response screenshot](images/index/logfire-screenshot-fastapi-422.png)

In the example above, we can see the FastAPI arguments failing (`user` is null when it should always be populated). This demonstrates type-checking from Pydantic used built-in with FastAPI.

## Structured data and SQL {#sql}

Query your data with SQL using familiar PostgreSQL-compatible syntax: all the control and (for many) nothing new to learn.

Logfire uses [Apache DataFusion](https://datafusion.apache.org/) as its query engine, which provides SQL syntax designed to match PostgreSQL conventions. See the [SQL Reference](reference/sql.md) for details.

Another big advantage is that generative AI tools like Claude Code or OpenAI Codex are excellent at writing SQL for you.

### Built for Agentic Coding Workflows

When you're using coding agents to iterate on AI applications, your agent needs to understand what's happening in production. Most observability tools limit agents to predefined APIs or proprietary query languages.

**Logfire gives agents full SQL access.**

```sql
-- Your coding agent can write queries like:
SELECT
  span_name,
  AVG(duration) as avg_latency,
  COUNT(*) as request_count,
  SUM((attributes->>'token_count')::int) as total_tokens
FROM records
WHERE service_name = 'my-ai-service'
  AND start_timestamp > NOW() - INTERVAL '1 hour'
GROUP BY span_name
ORDER BY avg_latency DESC;
```

This means:

- **No artificial limitations**: Ask any question, get any answer
- **AI assistants excel at SQL**: GPT-5, Claude, and other LLMs write excellent SQL
- **Arbitrary analysis**: Correlations, patterns, edge cases, whatever you need
- **Familiar syntax**: No new query language to learn

When a coding agent is debugging your AI application, it shouldn't be limited by what queries someone anticipated. It should have full access to understand what's actually happening.

Just include your structured data in **Logfire** calls (for example, in Python that means lists, dicts, dataclasses, Pydantic models, DataFrames, and more)
and it'll end up as structured data in our platform ready to be queried.

For example, using data from a `User` model, we could list users from the USA:

```sql
SELECT attributes->'result'->>'name' as name, extract(year from (attributes->'result'->>'dob')::date) as "birth year"
FROM records
WHERE attributes->'result'->>'country_code' = 'USA';
```

![Logfire SQL Workbench query screenshot](images/index/logfire-screenshot-explore-query.png)

You can also filter to show only traces related to users in the USA in the live view with

```sql
attributes->'result'->>'name' = 'Ben'
```

![Logfire search query screenshot](images/index/logfire-screenshot-search-query.png)

Structured Data and SQL Access with familiar syntax means you can use AI for SQL generation, ensuring your Python objects and structured data are query-ready.