ETS Tables

Analogy categoryAnalogies

What Is ETS?

ETS (Erlang Term Storage) is a built-in in-memory storage engine that lets a process create a table with ets:new(Name, Options) and store arbitrary tuples in it, where by default the first element of each tuple serves as the table's key. Unlike ordinary process state, which lives on a single process's heap and can only be read by sending it a message, an ETS table lives outside any process heap in its own dedicated memory area, so other processes can read (and, depending on access rights, write) its contents directly and concurrently without going through the owning process's mailbox at all.

🏏

Cricket analogy: A stadium's shared electronic scoreboard can be read directly by every camera operator and commentator simultaneously without radioing the scorer for each update, the same direct concurrent access an ETS table gives multiple processes instead of routing every read through a message to the owning process.

Table Types and Concurrency Options

The Options passed to ets:new/2 control both the table's data-structure semantics and its concurrency model. The type option is one of set (one entry per unique key, the default), ordered_set (also unique keys, but stored in a balanced tree so ets:first/1 and ets:next/2 traverse keys in sorted order), bag (multiple distinct objects per key allowed), or duplicate_bag (multiple objects per key, duplicates allowed). Independently, the access option, public, protected (the default: any process can read, only the owner can write), or private (only the owner can read or write at all), determines which processes are even allowed to call ets:insert/2 or ets:lookup/2 against the table in the first place.

🏏

Cricket analogy: A stats database enforcing one row per player (set) versus one that keeps every individual innings score for that player (bag) mirrors ETS's set-versus-bag distinction, while a public leaderboard anyone can view but only the official scorer can edit mirrors ETS's protected access mode.

named_table lets other processes reference the table by the atom you passed to ets:new/2 (e.g. ets:lookup(scores, alice)) instead of needing the opaque table identifier returned by ets:new/2, which is convenient for singleton tables owned by a well-known gen_server.

Inserting, Looking Up, and Querying Data

Data is written with ets:insert(Table, Tuple), or ets:insert(Table, [Tuple1, Tuple2]) for a batch, and read back by exact key with ets:lookup(Table, Key), which always returns a list (empty if the key is absent, since a bag or duplicate_bag can legitimately return more than one object). For queries beyond an exact key match, ets:match/2 and ets:match_object/2 accept a pattern with the special atom '_' as a wildcard, while ets:select/2 takes a compiled match specification and can filter and project fields far more efficiently than fetching every row and filtering in Erlang code, because the filtering runs inside the BEAM's C-level table-scanning code rather than as interpreted Erlang.

🏏

Cricket analogy: Looking up one player's exact stat line in a database is a direct hit, but finding 'every player with a strike rate above 150' needs a filtered query rather than fetching every player and checking manually, mirroring how ets:select/2 pushes the strike-rate filter down into fast native code instead of filtering in Erlang after ets:lookup.

erlang

-module(ets_demo).
-export([demo/0]).

demo() ->
    Tab = ets:new(scores, [set, protected, named_table]),
    ets:insert(Tab, {alice, 92}),
    ets:insert(Tab, {bob, 78}),
    ets:insert(Tab, {carol, 85}),

    [{alice, Score}] = ets:lookup(Tab, alice),
    io:format("Alice's score: ~p~n", [Score]),

    %% Find everyone scoring 80 or above using a match specification.
    HighScorers = ets:select(Tab, [{{'$1', '$2'},
                                    [{'>=', '$2', 80}],
                                    ['$1']}]),
    io:format("High scorers: ~p~n", [HighScorers]),

    ets:update_counter(Tab, bob, {2, 5}),
    io:format("Bob's new score: ~p~n", [ets:lookup(Tab, bob)]),

    ets:delete(Tab).

Ownership, Lifetime, and Performance Considerations

An ETS table belongs to the process that created it and, by default, is automatically destroyed the moment that owning process terminates, which is why long-lived tables are typically owned by a supervised gen_server or given away with ets:give_away/3 to a more stable process, or assigned a heir with the heir option so ownership transfers automatically on the owner's death instead of the data simply vanishing. A crucial performance nuance is that ETS memory is not part of any process's heap, so it is never touched by that process's garbage collector, reading a large object out of a table with ets:lookup/2 copies it into the calling process's heap, and writing one with ets:insert/2 copies it out, which is what keeps ETS tables from causing the long GC pauses that storing the same amount of data in a single process's own state would.

🏏

Cricket analogy: A stadium's ground curator retiring doesn't erase the pitch report archive if it was formally handed to the venue's permanent records office ahead of time, the same 'heir' handoff ets:new's heir option provides so a table survives its creating process's exit instead of vanishing with it.

ets:lookup/2 and friends copy data between ETS memory and the calling process's heap on every call, for very large individual objects or extremely hot lookup paths, that copy cost is real and worth benchmarking; ETS trades per-call copying overhead for freedom from GC pauses, it does not eliminate copying altogether.

ets:new(Name, Options) creates an in-memory table that lives outside any process's heap and can be read (and sometimes written) by multiple processes concurrently.
The type option (set, ordered_set, bag, duplicate_bag) controls key uniqueness and ordering; the access option (public, protected, private) controls which processes may read or write.
ets:insert/2 writes, ets:lookup/2 reads by exact key and always returns a list, and ets:select/2 with a match specification filters efficiently inside native table-scanning code.
A table is destroyed when its owning process dies unless ownership is transferred with ets:give_away/3 or a heir is configured at creation.
ETS data is never scanned by a process's garbage collector, avoiding GC pauses that large in-process state would cause, at the cost of copying data in and out of the process heap on each read/write.
named_table lets you reference a table by its declared atom name instead of the opaque reference ets:new/2 returns.