Let me given you an example case which uses both GenServer and ETS from the application I’m working on. My only caution is that I’m not very experienced with Elixir or other BEAM based applications so I may well, “be doing it wrong”.

In my application, there are a fair number of user maintainable settings which influence runtime behavior of the application for that tenant. These settings are persisted in the backend database, but the usage pattern is that any given setting will have its value read pretty frequently, but changed relatively rarely.

While I could retrieve setting values from the database on-demand, the fact that these settings are relatively static over time makes me think that’s a lot of avoidable noise to/from the database and that I am probably better off caching those settings in some way. So what I do is I have a GenServer for each tenant that loads all the settings from the database for that tenant on start-up. The GenServer itself creates an ETS table to load the settings into, rather than keep the settings as the GenServer state. The GenServer is the parent process of the ETS table and the ETS table is setup as a protected ETS table.

When the application needs to retrieve a setting value, the application directly reads the value from the ETS table. ETS reads are concurrent and shouldn’t block others reading or writing settings; as @benwilson512 says, this avoids the bottleneck that GenServers process a single message at a time. When a user decides to update a setting, this gets sent to the GenServer via a call; while ETS writes are concurrent, I want something that looks atomic between the ETS table and updating the setting in the long term persistence of the database (admittedly, looks atomic at a distance). So, because, the GenServer only processes one message at a time, it effectively serializes any setting update which is just a touch easier to reason about in my use case. Again, I expect writes to be rare, so concurrent writes aren’t essential in this case. Also, for my use case, while the settings are relatively static, there will be many of them. Accessing the settings via the ETS API feels more natural than having to parse through a larger state object that a GenServer will keep, even if those APIs aren’t in any sense “bad” or “cumbersome”.

To my mind, there is certainly a a bit of overlap of cases where either a GenServer or ETS tables would make roughly the same sense for sure which is why it can be a bit confusing. For me, it boils down to the relative weights of need for concurrency, controls, and perhaps the size of the state to be managed, though I’m much less firm commitment on that last point.