A simple benchmark script:

from datetime import date, timedelta
import json, orjson, ujson
import timeit
from pydantic import BaseModel, TypeAdapter

class Response(BaseModel):
    values: dict[int, dict[date, float]]

def make_response(n: int, m: int) -> Response:
    base = date(2025, 1, 1)
    values = {
        i + 1: {base + timedelta(i + j): (i + j) / 12.3 for j in range(m)}
        for i in range(n)
    }
    return Response(values=values)

ta = TypeAdapter(Response)
r = make_response(2, 20)
cases = {
    "json": "json.dumps(ta.dump_python(r, mode='json'), ensure_ascii=False).encode()",
    "ujson": "ujson.dumps(ta.dump_python(r, mode='json'), ensure_ascii=False).encode()",
    "orjson": "orjson.dumps(ta.dump_python(r, mode='json'), option=orjson.OPT_NON_STR_KEYS)",
    "pydantic": "ta.dump_json(r)",
}
for case, code in cases.items():
    print(case, min(timeit.repeat(code, number=10000, globals=globals())))

Results:

json 0.23686759299016558
ujson 0.12213927501579747
orjson 0.09217712600366212
pydantic 0.06348165299277753

@YuriiMotov thanks for taking a look! This PR was intentionally minimal just to demonstrate the idea. I'm happy to add more tests and update documentation if the fastapi team agrees on the approach, especially since this is a user visible feature.

@YuriiMotov I addressed your comments. Please take another look.

I forgot to inform - we discussed this idea with Sebastian and he said he'd like to take a look at this later as he has his own thoughts regarding the implementation. So, let's wait.

@YuriiMotov sounds good. thanks for letting me know

Merging this PR will not alter performance

✅ 20 untouched benchmarks

_{Comparing eltoder:feature/pydantic-json-response (6706439) with master (8c32e91)}

Hi @YuriiMotov! Do you have any ETA on when this is going to be reviewed?

Hi @YuriiMotov! Do you have any ETA on when this is going to be reviewed?

Unfortunately no ETA

This pull request has a merge conflict that needs to be resolved.

Since FastAPI 0.130.0 if you specify response model and don't specify response class, FastAPI bypasses json_serializer and serialize response data on Pydantic's side.

See: #14962

So, this PR is not needed anymore and may be closed.

@eltoder, thanks for your efforts!

@YuriiMotov what if I need a custom content type?

@YuriiMotov what if I need a custom content type?

I see what you mean..

As I see it, the ability to bypass jsonable_encoder would be a solution here (something like disable_jsonable_encoder parameter. Or even disable_jsonable_encoder attribute of response class), right?
This would enable the ability to use your own response class and have full control over the serialization.

This would also solve use cases like #14929

I agree that this should be controlled by the response class. This is what I did in this PR. Instead of a boolean attribute this is usually done with a marker class like NoJsonableEncoderResponse which one can inherit into their response classes. This is similar to the current solution, but will be more ergonomic.

Back on the original subject. Note that automatically enabling pydantic json serialization like in #14962 is a backwards incompatible change. Pydantic's serialization behavior is different from the previous behavior.

@YuriiMotov it appears that #14962 was reverted. Please re-open this PR.

EDIT: I take it back. The revert commit a0a2d84 is not on any branch.

@YuriiMotov it appears that #14962 was reverted. Please re-open this PR.

EDIT: I take it back. The revert commit a0a2d84 is not on any branch.

It was in this PR just to test performance impact one more time. That PR was closed

Back on the original subject. Note that automatically enabling pydantic json serialization like in #14962 is a backwards incompatible change. Pydantic's serialization behavior is different from the previous behavior.

I think I agree it might be breaking, but could you please share a use case you have in mind?