Pydantic BaseModel vs dataclasses in FastAPI

WHAT THIS TESTS Whether you understand that dataclasses are containers while Pydantic models are a validation, parsing, and serialization layer, and why FastAPI is built around the latter.

A GOOD ANSWER COVERS The central difference is runtime enforcement. A dataclass uses type hints purely for readability and tooling; assigning a string where an int is annotated raises no error at runtime, so invalid data flows through. Pydantic's BaseModel validates and coerces incoming data when the model is constructed: it parses JSON-friendly inputs into proper types, enforces constraints like min length or ranges via Field, supports custom and computed validators, and raises a structured ValidationError on bad input. It also handles serialization both ways with model_validate and model_dump, including JSON. Critically for FastAPI, BaseModel integrates with the framework to auto-generate the OpenAPI schema, power interactive docs, and drive automatic request body parsing and response shaping. None of this comes from a plain dataclass. Pydantic also offers aliases, default factories, nested model validation, and settings management.

COMMON WRONG ANSWERS Asserting that dataclasses validate types at runtime, they do not. Claiming both give FastAPI automatic docs and validation. Saying dataclasses are always faster so they are preferable, ignoring that you would have to hand-write validation. Overlooking serialization differences.

LIKELY FOLLOW-UPS When would a dataclass still be appropriate? What does Pydantic v2's Rust core change about performance? Can FastAPI use dataclasses at all, and with what limits?

ONE CONCRETE EXAMPLE Given class User(BaseModel): age: int, passing {'age': '30'} from JSON yields age == 30 as an int, and {'age': 'old'} raises a clear ValidationError that FastAPI turns into a 422. An equivalent @dataclass User would store age = '30' as a string with no complaint, leaving the bug to surface deep in business logic.