TL; DR
These are tools created for different purposes: ETS is a quick K / V store, Mnesia is a database built on their basis. Use the tool that suits your use case.
Discussion
Mnesia is built on top of ETS / DETS. Which is more efficient comes down to what features you are looking for. If you have simple tables without additional logic, one simple key for indexing and will use the table only in memory or from disk, then there is no difference between ETS and Mnesia, and you will not use any Mnesia functions.
If, on the other hand, you need several indexes on the data, you want to implement some caching behavior, you need to constantly save it to disk, but the performance of the cached index and other things that you expect from a database system, then you either have to use functions like Mnesia directly over ETS / DETS or just use Mnesia.
Very often, I start with several ETS tables when prototyping (or even in earlier versions of functions in production), and then I start looking for places where I need data serialized on disk, then I understand that I need several indexes, etc. . in any case, the transfer of a large amount of data management material that was originally in the ETS in Mnesia. If you distract the concept of data access properly, it is not a problem to change the implementation of this part of your system in any way. However, if you have selective calls scattered across all of your modules, then you probably have other architectural issues that are much more important than ETS vs Mnesia.
No matter what you use, make sure that you are not doing something like creating a system-wide bottleneck as a central repository of all state for the entire system. This is mistake. I see a lot of people coming from a view (C / Python / $ imperative_lang + Postgres / MariaDB / $ rbdms).
Read paragraphs 2-6. ErlMUD Comment: Architecture, Location for an architectural discussion of the state's presentation at a high level.