Unity DOTS: what it is and when to use it in production

Unity DOTS, short for Data-Oriented Technology Stack, is Unity's high-performance path built on Entities (ECS), the C# Job System, and the Burst compiler. Production teams pick Unity DOTS when a project must simulate tens of thousands of active agents, physics bodies, or projectiles at stable frame rates on mobile or desktop hardware, where classic MonoBehaviour hits a wall.

Why Unity DOTS exists: cache-friendly data and multi-core CPUs

Classic Unity code stores gameplay state inside MonoBehaviour objects scattered across managed heap memory. Every Update call chases pointers across the heap, thrashes the CPU cache, and runs on a single main thread. Unity DOTS flips that layout: data lives in tight contiguous chunks per archetype, code runs as jobs across worker threads, and Burst compiles the hot path to native SIMD instructions.

The practical outcome is a shift from "a few hundred active objects" to "tens of thousands" on the same device, provided the systems are written in the DOTS style.

Entities: the ECS core of the Data-Oriented Technology Stack

Entities is the ECS package that carries the Data-Oriented Technology Stack. An entity is an integer id, a component is a plain data struct, and a system is a job that iterates over entities with a matching set of components. Archetypes group entities with identical component layouts into contiguous chunks, which is what makes iteration cache-friendly.

Entities 1.0 stabilized in 2023 and shipped with a maintained API surface, baking pipeline, and subscene workflow. Unity 6 ships Entities 1.3 with better editor tooling and clearer upgrade rules for teams already on the 1.x line.

The Burst compiler: native performance for C# jobs

Burst is an ahead-of-time compiler that turns a restricted subset of C# into native code with SIMD vectorization. In practice it gives math-heavy jobs performance close to hand-written C++ without leaving the C# codebase.

Burst is production-ready and used well beyond DOTS itself. It powers parts of Unity Physics, the Animation C# Jobs API, and any custom IJob implementation that opts into the [BurstCompile] attribute. For a Unity DOTS project, Burst is not optional. Without it, ECS systems lose most of their advantage over classic MonoBehaviour code.

The C# Job System: safe multithreading for gameplay code

The C# Job System is Unity's safe way to run gameplay code across worker threads. It uses the Burst-friendly Native Collections and a static safety system that flags data races at compile time, not at runtime.

Inside Unity DOTS, every ECS SystemBase or ISystem naturally schedules its work as jobs. Outside DOTS, the same Job System can be used to parallelize particle updates, procedural mesh generation, pathfinding, or AI evaluations without touching Entities at all.

DOTS Physics versus classic PhysX in Unity

Unity ships two physics engines. Classic Unity Physics uses PhysX, is fully deterministic per-machine but not across machines, and lives on MonoBehaviour Rigidbody and Collider components. Unity Physics for Entities ("DOTS Physics") is stateless, deterministic across machines when configured correctly, and designed to scale to thousands of active bodies via jobs and Burst.

For simulation-heavy multiplayer, RTS, or crowd systems, DOTS Physics is a strong fit. For a linear single-player title with a few dozen rigidbodies, PhysX remains the simpler choice. Havok Physics for Unity offers a higher-fidelity stateful option on top of the same Entities data.

Netcode for Entities: high-scale multiplayer, with caveats

Netcode for Entities is Unity's ECS-based multiplayer package. It uses a server-authoritative model with client-side prediction and snapshot interpolation, built directly on Entities and jobs so that the network loop stays inside the DOTS performance envelope.

As of the Unity 6 LTS cycle, Netcode for Entities is still marked experimental. For production shooters, RTS, or MMO prototypes it is usable, but teams should expect API changes between minor versions and budget for netcode-specific QA rather than treating it as a drop-in replacement for Netcode for GameObjects.

URP and Entities Graphics: rendering the DOTS world

Entities Graphics, formerly Hybrid Renderer, is the package that draws ECS entities on screen. It integrates with the Universal Render Pipeline (URP) and supports instanced rendering, LOD, skinning, and lightmaps for entity-based content.

HDRP support exists but is narrower in scope, so most Unity DOTS titles ship on URP. For mobile and mid-range PC hardware this is the right pick anyway, since URP is where Unity focuses graphics performance work on those platforms.

When to use Unity DOTS versus classic MonoBehaviour

Pick Unity DOTS when the project's core loop is simulation-bound: tens of thousands of active agents, projectiles, particles, physics bodies, or grid cells that must update every frame. Typical fits are RTS, autobattlers, city-builders, tower defense at large scale, crowd simulations, bullet-hell shooters, and server-side simulation for competitive multiplayer.

Stay on classic MonoBehaviour when the game is content-heavy but not simulation-heavy: narrative titles, most third-person adventures, casual mobile puzzlers, hidden object games. The MonoBehaviour authoring workflow is faster, the asset store ecosystem is richer, and the performance ceiling is high enough for those genres.

A hybrid setup is common in practice. Gameplay logic that fits ECS runs as Entities, while UI, cutscenes, and authoring tools stay on MonoBehaviour. Entities and GameObjects can coexist in the same scene through subscenes and companion components.

MonoBehaviour + PhysX vs DOTS Entities + DOTS Physics

The table below summarizes how the two stacks compare for a production team scoping a new Unity project.

Performance orders of magnitude teams should expect

Public Unity samples and independent benchmarks converge on similar orders of magnitude. A boid simulation that peaks around 3-5 thousand agents on MonoBehaviour can run 50-100 thousand agents on Unity DOTS on the same mid-range desktop CPU, because the work is spread across cores and the inner loop runs Burst-compiled SIMD code.

Physics scales similarly. DOTS Physics can simulate 10-20 thousand active rigid bodies where PhysX starts dropping frames around 1-2 thousand. Numbers vary by scene complexity, collision layer setup, and CPU, so treat these as rough guides, not guarantees. Any real project should benchmark its own worst-case scene before locking the stack.

Migration paths from MonoBehaviour to Unity DOTS

Full migration of an existing MonoBehaviour codebase to Entities is rarely the right call. The realistic path is incremental. Identify the systems that are CPU-bound, port those to Entities and jobs, and leave the rest on MonoBehaviour.

A typical order looks like this:

This order keeps the game shippable at every step and avoids the rewrite-then-pray pattern that has killed more than one DOTS migration.

Production caveats teams should plan for

Unity DOTS is production-ready for its core (Entities, Burst, Job System, DOTS Physics) but the surrounding ecosystem is thinner than classic Unity. Asset store coverage is smaller, third-party tool integrations sometimes lag a version behind, and hiring engineers with real ECS shipping experience takes longer than hiring generalist Unity devs.

Debugging is different too. Entities Journaling and the Entities Hierarchy window help, but stack traces jump through baking, systems, and Burst-compiled code in ways that new team members find disorienting for the first few weeks. Plan onboarding time, code reviews for cache-unfriendly patterns, and a shared style guide before scaling the team on ECS work.

When to talk to Game-Ace about Unity DOTS

Unity DOTS work is where a data-oriented mindset, ECS experience, and honest scoping matter more than raw Unity hours. Game-Ace has been shipping Unity titles since 2005 with a 120+ in-house team, so a DOTS conversation can start with an architecture review of the intended core loop, an honest read on whether Entities is the right pick, and a phased plan if it is. When Unity is part of your roadmap, Game-Ace, a custom Unity game development studio, covers full-cycle delivery, co-development, and team extension from a single team. See our Unity game development and hire Unity developers pages, plus the Unity for game development and Unity 6 guides.