Dataclasses vs Pydantic: A Performance and Memory Footprint Comparison

2025-06-04

When building Python applications that handle structured data, you often need to choose between different approaches for modeling your data. Two popular options are Python's built-in dataclasses and the third-party Pydantic library. In this comparison, we'll examine the speed and memory characteristics of both approaches across various scenarios, including validation performance.

I tested regular dataclasses, frozen dataclasses, slotted dataclasses, and Pydantic models to help you make an informed decision for your specific use case. Important note: This comparison focuses on basic validation scenarios. Pydantic offers significantly more sophisticated validation capabilities that aren't fully represented in these benchmarks.

Understanding What We're Comparing

Before diving into the numbers, let me clarify what each approach offers. Regular dataclasses represent Python's standard library solution for reducing boilerplate by automatically generating special methods like __init__ and __repr__ based on your field annotations. When you add the frozen=True parameter, you get immutable dataclasses that prevent modification after creation, which can be invaluable for thread safety and preventing accidental mutations.

Slotted dataclasses take things a step further by using __slots__ to reduce memory usage and slightly improve attribute access speed. This optimization comes at the cost of flexibility—you can't dynamically add attributes later—but the performance gains can be significant when working with large numbers of objects.

Pydantic models represent a different philosophy entirely. While they provide similar functionality to dataclasses, they emphasize runtime type checking, comprehensive validation, automatic type coercion, and serialization capabilities. This makes them incredibly powerful for handling external data, API validation, and complex data transformations, but as we'll see, this power comes with performance implications.

Testing Methodology

I designed my benchmarks around several key scenarios that matter in real-world applications. Object creation speed matters when you're processing large datasets or handling high-frequency requests. Attribute access performance becomes critical in tight loops or when accessing properties repeatedly. JSON serialization is ubiquitous in modern web applications. Validation performance is crucial when processing external data. And memory usage can significantly affect applications that need to scale.

Testing Environment: All benchmarks were run on Python 3.11+ with Pydantic v2.x. Results may vary across different Python versions and hardware configurations. Each benchmark was run multiple times to ensure consistency.

Here's the complete benchmark code I used for my tests:

import json
import time
import tracemalloc
from dataclasses import asdict, dataclass
from typing import Any, Union

from pydantic import BaseModel


class DataclassValidatorMixin:
	def validate(self) -> None:
		for field_name, field_type in getattr(self.__class__, '__annotations__', {}).items():
			if hasattr(self, field_name):
				value = getattr(self, field_name)
				self._validate_field(field_name, value, field_type)

	def _validate_field(self, field_name: str, value: Any, field_type: type) -> None:
		# Handle Union types (like float | None)
		if hasattr(field_type, '__origin__') and field_type.__origin__ is Union:
			# Get non-None types from Union
			valid_types = [t for t in field_type.__args__ if t != type(None)]
			if value is not None and not any(isinstance(value, t) for t in valid_types):
				raise ValueError(f"Field '{field_name}' must be one of {valid_types}, got {type(value)}")
			return

		# Basic type checking
		if not isinstance(value, field_type):
			# Special handling for numeric conversions
			if field_type == float and isinstance(value, int):
				return  # int can be converted to float
			raise ValueError(f"Field '{field_name}' must be of type {field_type.__name__}, got {type(value).__name__}")


@dataclass
class RegularDataClass(DataclassValidatorMixin):
	name: str
	age: int
	email: str
	salary: float | None = None

@dataclass(frozen=True)
class FrozenDataClass(DataclassValidatorMixin):
	name: str
	age: int
	email: str
	salary: float | None = None


@dataclass(slots=True)
class SlottedDataClass(DataclassValidatorMixin):
	name: str
	age: int
	email: str
	salary: float | None = None


@dataclass(frozen=True, slots=True)
class FrozenSlottedDataClass(DataclassValidatorMixin):
	name: str
	age: int
	email: str
	salary: float | None = None


class PydanticModel(BaseModel):
	name: str
	age: int
	email: str
	salary: float | None = None



test_data = {"name": "John Doe", "age": 30, "email": "john.doe@example.com", "salary": 75000.0}


def benchmark_creation(cls: Any, iterations: int = 1_000_000) -> int:
	t0 = time.perf_counter()

	for _ in range(iterations):
		_ = cls(**test_data)

	return int((time.perf_counter() - t0) * 1000)


def benchmark_attribute_access(obj: Any, iterations: int = 10_000_000) -> int:
	t0 = time.perf_counter()

	for _ in range(iterations):
		_ = obj.name
		_ = obj.age
		_ = obj.email
		_ = obj.salary

	return int((time.perf_counter() - t0) * 1000)


def benchmark_validation_dataclass(cls: Any, iterations: int = 100_000) -> int:
	t0 = time.perf_counter()

	for _ in range(iterations):
		obj = cls(**test_data)
		obj.validate()

	return int((time.perf_counter() - t0) * 1000)


def benchmark_validation_pydantic(cls: Any, iterations: int = 100_000) -> int:
	t0 = time.perf_counter()

	for _ in range(iterations):
		_ = cls(**test_data)

	return int((time.perf_counter() - t0) * 1000)


def benchmark_json_serialization_pydantic(obj: Any, iterations: int = 100_000) -> int:
	t0 = time.perf_counter()

	for _ in range(iterations):
		json.dumps(obj.model_dump())

	return int((time.perf_counter() - t0) * 1000)


def benchmark_json_serialization_dataclass(obj: Any, iterations: int = 100_000) -> int:
	t0 = time.perf_counter()

	for _ in range(iterations):
		json.dumps(asdict(obj))

	return int((time.perf_counter() - t0) * 1000)


def measure_memory_usage_mb(cls: Any, num_objects: int = 100_000) -> float:
	tracemalloc.start()

	objects = []
	for _ in range(num_objects):
		objects.append(cls(**test_data))  # noqa: PERF401

	_, peak = tracemalloc.get_traced_memory()
	tracemalloc.stop()

	return peak / 1024 / 1024


# Run benchmarks
classes_to_test = [
	("Pydantic Model", PydanticModel),
	("Regular Dataclass", RegularDataClass),
	("Frozen Dataclass", FrozenDataClass),
	("Slotted Dataclass", SlottedDataClass),
	("Frozen + Slotted Dataclass", FrozenSlottedDataClass),
]

# Object Creation Benchmark
print("\n1. Object Creation (100,000 iterations)\n" + "-" * 40)
for name, cls in classes_to_test:
	print(f"{name:<30}: {benchmark_creation(cls)} ms")

# Attribute Access Benchmark
print("\n2. Attribute Access (1,000,000 iterations)\n" + "-" * 40)
for name, cls in classes_to_test:
	obj = cls(**test_data)
	print(f"{name:<30}: {benchmark_attribute_access(obj)} ms")

# Validation Benchmark
print("\n3. Validation (100,000 iterations)\n" + "-" * 40)
for name, cls in classes_to_test:
	if issubclass(cls, BaseModel):
		print(f"{name:<30}: {benchmark_validation_pydantic(cls)} ms")
	else:
		print(f"{name:<30}: {benchmark_validation_dataclass(cls)} ms")

# JSON Serialization Benchmark
print("\n4. JSON Serialization (10,000 iterations)\n" + "-" * 40)
for name, cls in classes_to_test:
	obj = cls(**test_data)
	if issubclass(cls, BaseModel):
		print(f"{name:<30}: {benchmark_json_serialization_pydantic(obj)} ms")
	else:
		print(f"{name:<30}: {benchmark_json_serialization_dataclass(obj)} ms")

# Memory Usage Benchmark
print("\n5. Memory Usage (10,000 objects)\n" + "-" * 40)
for name, cls in classes_to_test:
	print(f"{name:<30}: {measure_memory_usage_mb(cls):.2f} MB")

Running Your Own Benchmarks

To run these benchmarks yourself, save the benchmark code above as benchmark.py. If you have UV installed, you can easily run it with: uv run --with pydantic benchmark.py in your terminal. Alternatively, install Pydantic with pip install pydantic and run python benchmark.py.

What the Numbers Revealed

After running these benchmarks across different scenarios, the results painted a clear picture of each approach's strengths and weaknesses. Keep in mind that these results reflect the specific test scenario and may vary based on your data complexity and usage patterns.

Object Creation Performance

The differences in object creation speed across 100,000 iterations were dramatic. Slotted dataclasses were fastest at 188ms, followed by regular dataclasses at 205ms. Interestingly, the frozen variants were significantly slower—440ms for frozen dataclasses and 425ms for frozen + slotted combinations. This overhead comes from the additional immutability enforcement mechanisms. Pydantic models were the slowest at 635ms, over 3x slower than regular dataclasses, reflecting the overhead of runtime validation, type checking, and internal metadata management.

Attribute Access Patterns

For attribute access over 1,000,000 iterations, slotted variants performed best at 239ms each. This improvement comes from their memory layout optimization, which reduces attribute lookup time by storing attributes in a fixed-size array rather than a dictionary. Surprisingly, Pydantic models (288ms) outperformed regular dataclasses (313ms) and frozen dataclasses (314ms), demonstrating efficient attribute access optimization once objects are created.

Validation Performance Analysis

The validation benchmarks revealed interesting trade-offs between manual and automatic validation approaches. Our custom DataclassValidatorMixin performed well for non-frozen dataclasses, completing the benchmark in around 106ms. The frozen dataclass variants took slightly longer at 130ms, likely due to additional immutability checks during validation.

Pydantic's validation was significantly faster at 62ms. This performance advantage comes from Pydantic v2's Rust-based implementation (pydantic-core), while our custom validation logic runs in pure Python. Important caveat: This comparison only tests basic type validation. Pydantic provides much more sophisticated validation (regex patterns, custom validators, nested object validation, etc.) that our simple mixin cannot match.

JSON Serialization Speed

When it came to JSON serialization over 10,000 iterations, all approaches performed reasonably well, but Pydantic models were approximately 5% faster than dataclass alternatives. Pydantic's model_dump() method is specifically optimized for serialization scenarios, whereas dataclasses rely on the generic asdict() function followed by json.dumps().

Memory Consumption Analysis

Memory usage differences were the most striking aspect of our benchmarks. Slotted variants used just 6.88MB for 10,000 objects, while regular and frozen dataclasses consumed approximately 44% more memory at around 9.93MB each. Pydantic models required a substantial 45.78MB—nearly 7x more than slotted dataclasses—due to validation metadata, internal caching structures, and the comprehensive feature set that enables advanced functionality.

Making the Right Choice

Choose slotted dataclasses with custom validation when performance and memory efficiency are critical, and you need to process large volumes of data after initial validation. They offer the fastest creation speed, excellent attribute access performance, reasonable validation capabilities, and the lowest memory footprint. However, they require manual validation logic and offer less flexibility for dynamic attribute access.

Choose Pydantic models when you need comprehensive validation, automatic type coercion, complex nested data handling, and frequent serialization/deserialization. The creation overhead and significantly higher memory usage are justified by automatic validation, superior error handling, JSON schema generation, extensive ecosystem integration, and robust handling of edge cases that manual validation often misses.

Choose regular dataclasses for simple data containers where you need some structure but minimal validation overhead. They offer a good balance between simplicity and functionality without external dependencies.

Practical Strategies

A hybrid approach often works best in production systems: use Pydantic for data validation at system boundaries (API endpoints, file parsing, external integrations), then convert to slotted dataclasses for internal processing and storage. This strategy provides validation safety where it matters most without incurring ongoing performance costs throughout your application.

For batch processing operations, the 3.3x creation speed difference between slotted dataclasses and Pydantic becomes critical when processing thousands or millions of records. In memory-constrained environments, slotted dataclasses' 85% memory reduction compared to Pydantic can be decisive for scalability. When validation is crucial but performance matters, consider implementing focused custom validation that addresses your specific requirements rather than generic type checking.

Important Limitations and Considerations

These benchmarks represent a specific scenario with simple data structures and basic validation requirements. In real-world applications, consider these factors:

Pydantic excels with complex nested data, custom validators, and automatic type coercion—features that weren't fully tested here. For API development, Pydantic's integration with FastAPI and automatic OpenAPI schema generation often outweighs performance concerns. Dataclasses shine in internal data processing where structure matters more than validation, and when you need maximum performance with minimal dependencies.

The custom validation mixin shown here is basic compared to Pydantic's comprehensive validation system. Production validation often requires handling edge cases, multiple validation rules, and detailed error reporting that simple type checking cannot provide.

Final Thoughts

The choice between dataclasses and Pydantic isn't about finding the universally "best" option—it's about understanding trade-offs and matching tools to requirements. Slotted dataclasses excel in pure performance scenarios where you control the data pipeline. Pydantic provides safety and convenience features at a measurable but often acceptable cost, especially when handling external or untrusted data. Custom validation mixins offer a performance-conscious middle ground but require additional development and maintenance effort.

Many successful applications use multiple approaches strategically: Pydantic for external interfaces and complex validation, dataclasses for internal data processing, and hybrid patterns that leverage the strengths of each approach where they're most beneficial.