Unity DOTS & ECS – When and How to Use It in 2026

A plain-language decision guide for solo Unity developers: what ECS really changes, when to skip DOTS entirely, when it earns its cost, and how to start with the Entities package without rewriting your whole game.

DOTS comes up in almost every Unity performance conversation, and it is easy to come away thinking you should be using it. Most solo developers should not, at least not for most of their game. A few should, for one specific part of it.

This guide helps you decide which group you are in. It does not include benchmarks. The only honest performance number is the one you measure in your own project with the Profiler.

What DOTS and ECS mean

DOTS is Unity’s Data-Oriented Technology Stack. The piece most people mean when they say “DOTS” is the Entities package, which Unity’s documentation describes as a data-oriented implementation of the Entity Component System architecture, or ECS.

ECS has three parts.

Entities are IDs. An entity is not an object with code. It is a lightweight identifier that a set of components hangs off. The docs compare it to a much lighter, unmanaged stand-in for a GameObject.

Components are plain data. A component is a small struct, such as a speed, a health value, or a direction. It has no Update method and no behavior.

Systems are the behavior. A system finds every entity with a certain set of components and runs the same logic over all of them, usually once per frame.

How that differs from GameObjects

With GameObjects and MonoBehaviours, each object carries its own data and its own code. A thousand bullets means a thousand scripts, each with its own Update, each reaching into memory wherever its data happens to live.

ECS flips this around. Entities with the same combination of components are grouped together, and their data is stored in tightly packed arrays, one array per component type. The Entities docs call each unique combination an archetype and the memory blocks that hold them chunks.

So instead of a thousand bullets each updating themselves, you have one movement system walking down an array of positions and an array of velocities. The CPU is good at that kind of work, and it is easy to split across worker threads with the job system and compile with Burst.

That is the real trade. You give up the convenience of “an object that does things” in exchange for “data laid out so one piece of code can process lots of it.”

When to skip DOTS

Skip it, or put it off, if any of these describe your project.

Your game has a modest number of active objects. A platformer, a puzzle game, a narrative game, a card game, or most small 3D adventures do not have enough similar things updating at once for the data layout to matter. Regular GameObjects are simpler and fine.

The work is UI. Menus, HUDs, inventories, and dialogue are about layout and events, not processing thousands of identical records. Keep them in Unity’s normal UI tools.

The logic is one-off gameplay. A boss with a unique attack pattern, a door puzzle, or a cutscene trigger runs once or a handful of times. ECS adds structure without giving you anything back.

You are still finding the fun. ECS asks you to plan your data before you build behavior. The Entities docs say as much: design your components before you write systems. That is the opposite of fast prototyping. Prototype with GameObjects first.

You rely on a lot of GameObject-based tools. ECS has its own workflow, its own scenes, and its own companion packages. Check that the tools you depend on fit before committing.

When DOTS earns its cost

DOTS starts to pay off when you have large numbers of similar things that all need the same update every frame. Common examples:

• Projectiles in a bullet-heavy shooter.
• Crowds, swarms, flocks, or herds.
• Many simple units in a strategy or survival game.
• Particle-like gameplay objects that need collisions or logic, not just visuals.
• Simulations such as traffic, growth, or spreading effects across a large grid.

The test is simple. If you would otherwise write one MonoBehaviour and put it on hundreds or thousands of objects, that system is a DOTS candidate.

It also helps to confirm the problem first. Open the Unity Profiler on a target device and look for where frame time goes. If a large share is spent in many copies of the same Update method, ECS may help. If the time is in rendering, physics settings, or garbage collection from one bad script, fix that first.

The hybrid approach

You do not have to choose all or nothing. A practical solo plan is to keep the game in GameObjects and move just the one heavy system into ECS.

Your player, camera, UI, menus, and level logic stay as they are. The swarm of enemies or the hail of bullets becomes entities. You learn ECS on one contained problem, and if it does not help, you have not rebuilt the game.

How to start

Here is a short path that follows Unity’s Entities documentation. Exact screens differ between editor versions, so keep the official docs open for yours.

1. Check compatibility and install the package. The installation page in the Entities manual lists the supported Unity versions. Install through the Package Manager window. If you add it by name, the docs give the package name as com.unity.entities.

2. Set up your IDE. The docs note that Entities relies on Roslyn source generators and list compatible versions of Visual Studio and Rider. An older IDE can flag valid code as errors.

3. Consider the play mode setting. The docs recommend disabling domain reloading for Entities projects and link to Unity’s page on configuring play mode settings. Read what that change affects before you flip it, especially static fields in your existing scripts.

4. Add companion packages only when needed. The docs say Entities is rarely used alone and list Entities Graphics, Unity Physics, and Netcode for Entities as common partners. If you want entities to show up on screen, start with the Entities Graphics docs.

5. Create a subscene and bake. In ECS, content lives in subscenes. You place ordinary GameObjects with authoring MonoBehaviours inside a subscene, and a process called baking converts them into entities and components in the editor. The docs suggest ending authoring class names with Authoring to keep things clear.

6. Write one component and one system. A component is a struct implementing IComponentData. An unmanaged system is a struct implementing ISystem, with OnCreate, OnUpdate, and OnDestroy. Inside OnUpdate, SystemAPI.Query lets you loop over every entity with the components you name.

using Unity.Burst;
using Unity.Entities;
using Unity.Mathematics;
using Unity.Transforms;

public struct Velocity : IComponentData
{
    public float3 Value;
}

[BurstCompile]
public partial struct MoveSystem : ISystem
{
    [BurstCompile]
    public void OnUpdate(ref SystemState state)
    {
        float dt = SystemAPI.Time.DeltaTime;

        foreach (var (transform, velocity) in
                 SystemAPI.Query<RefRW<LocalTransform>, RefRO<Velocity>>())
        {
            transform.ValueRW.Position += velocity.ValueRO.Value * dt;
        }
    }
}

RefRW marks data the system writes. RefRO marks data it only reads. That distinction lets Unity schedule work safely. Once this runs correctly, the docs show how to move the same logic into an IJobEntity job so it can run across worker threads.

Pitfalls to watch for

Old tutorials. The Entities docs mark Entities.ForEach as obsolete and point you to SystemAPI.Query and IJobEntity instead. If a tutorial leans on Entities.ForEach, it was written for an older version.

Structural changes. Adding or removing components, or creating and destroying entities, moves data between archetypes. The docs warn that doing this often is expensive. Prefer changing component values over changing which components an entity has, and batch structural changes with an entity command buffer.

Too much, too soon. Converting a whole project is a large job. Start with one system, measure it in the Profiler, and expand only if the results justify it.

The short version

Use GameObjects for almost everything a solo developer builds. Reach for ECS when you have one system with a large crowd of similar things, you have profiled it, and the profiler points at that system. Keep the rest of the game where it is, and let the official Entities docs guide each step for your editor version.