You could simulate the complete interface of the :ets module with GenServer. However, such implementation would be very inefficient in some cases.

A typical example is in memory k-v. If you do this with a single process (GenServer or Agent), then all access is serialized. If you have thousands of client processes interacting with such k-v, operations are performed one at a time.

In contrast, an ETS powered table with proper knobs turned on (:public, :read_concurrency, :write_concurrency) will allow different clients to interact with the same table simultaneously. Multiple processes can issue reads and writes to the same table at the same time, and the operations can be performed simultaneously, unless both processes are writing to the same row.

An example of this in practice is Registry, which is powered by ETS tables. This ensures that client processes can quickly find desired processes, and even get some of their properties, without needing to message some process.

The thing @rvirding and @Nilithus mentioned about avoiding large process heap is also an interesting feature. ETS data is “off-heap”, so it doesn’t put any pressure on GC. If you have a single process with a large, and frequently changing, active memory set, ETS table might improve your performance significantly.

So basically, ETS is mostly an optimization technique. If your needs are simple, you can probably start with a GenServer, and consider ETS if you find performance problems.

Using ETS as a cache is only one of its many uses. A major use is for storing LARGE amounts of data in memory. This is a typical use, for example it is how mnesia stores data in memory. So if your gen_server stores large amounts of data then maybe using ETS is a better alternative.

As has already been pointed out ETS tables can be shared between processes. One thing to watch out is that ETS is a datastore not a database and the support for transactions is VERY limited. If you need to implement transactions you will probably need a process in front of the ETS tables.

There are many other uses of ETS. Another one for example is having supervisor use ETS tables to share data between its children, both current and future ones.

So in Erlang ETS is used quite often.

No expert here – but from the reading I’ve done 90% of the time you’re better off just storing state in the GenServer.

There is a couple of interesting use cases since ETS tables have some access control:

public — Read/Write available to all processes.
protected — Read available to all processes. Only writable by owner process. This is the default.
private — Read/Write limited to owner process.

so you can have shared state across processes. I believe the Elixir Registry uses ETS tables under the hood.

The other use case I’ve seen is if you are highly concerned about Garbage Collection(GC) cycles the ETS table is not stored in the process’s heap. This Erlangelist blog article talks about saving GC latency when you have large data buffered in a process.

But these are all pretty big edge cases I think. Hope this helps!