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...

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.

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

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

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.

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

The Chad answer is to use pydantic.dataclass