To help answer your question, here's a detailed comparison from the attrs project:

https://www.attrs.org/en/stable/why.html

There's some obvious potential for bias there, but I thought most of the arguments were well reasoned.

Edit: found another that I thought was helpful: https://threeofwands.com/why-i-use-attrs-instead-of-pydantic...

Why would I use a Pydantic model when `TypeAdapter(MyDataclass)` exists?

Performance hit from data validation at construction time. I like msgspec which is much leaner and faster.

My rule of the thumb is that Dataclasses are for compile-time type-checking, pydantic classes are for run time type checking.

Unnecessary baggage if you don't need validation or serialisation.

My rule of thumb is to use Pydantic if I need serialisation, otherwise I default to dataclasses.

This and not just for the performance reasons. A Pydantic model represents an I/O boundary of a program. This conveys a lot of information to a programmer reading the code. It would be quite misleading to find it's actually only passed around internally and never used for I/O. A bit like using an int type to store a Boolean value.

On the other hand if I see a dataclass I can tell what it's purpose is by whether it's frozen or not etc.

Always strive for self-documenting code.

Main reason is (used to be) performance. But since pydantic 2.0 it’s not an issue anymore I default to use pydantic for everything.

The Chad answer is to use pydantic.dataclass

One explicit difference is that dataclasses don't support validating nested objects.

I'd use it for passing flat structures as function args rather than a massive list of individual args.