Pydantic

Using Pydantic models as primary data structures beyond API boundaries creates significant 'serialization/deserialization debt'. Pydantic object creation is 6.5x slower than Python dataclasses, memory usage is 2.5x higher, and JSON operations are 1.5x slower. This compounds quickly with thousands of objects.

Migrating from Flask or Django to FastAPI requires replacing familiar tools: `requests` must be replaced with `httpx` for async operations, Django REST Framework serializers must become Pydantic models, and the async paradigm shift is non-trivial. FastAPI lacks the built-in ORM and admin panel developers relied on.

Several important features needed for production usage (e.g., hiding attributes from Swagger, hiding internal documentation from Pydantic docstrings) have had PRs submitted but remain unmerged without maintainer feedback or response.

When using type hints or `response_model`, FastAPI performs double validation—once during request parsing and again during response model creation. This adds 20-50% overhead to response processing and should be avoided by returning raw data instead.

FastAPI's specific syntax and reliance on asynchronous programming, standard Python type hints, and Pydantic increases the learning curve significantly for developers unfamiliar with these concepts, potentially slowing onboarding and adoption.

FastAPI uses Pydantic for validation, but there is no straightforward way to pass custom validation messages from the validation point to the API response, forcing developers to use whatever generic messages Pydantic provides.