What is the performance impact of modules that use Field API instead of a custom way of accessing the database?

Question

This answer states that it is better to share fields among content types when possible because each field added slightly negatively impacts performance. Assuming this answer and my interpretation of it is correct, for nodes that already have lots of fields for unavoidable reasons, would avoiding the use of modules that make use of the Field API when alternatives are available enhance site performance?

For example:

• Meta Tags instead of Meta Tags Quick

Answer 1

That can't be answered in a generic way, I think. Some facts:

• Each field does add a certain overhead to the system and it means more queries when loading and saving e.g. nodes.
• Being able to store information as a separate entity that has the information as properties is obviously much faster than having everything in fields.
• However, modules that stores additional information to entities on it's own tables results in additional queries as well.
• The advantage of field API is that the storage is pluggable, so you could for example use it together with MongoDB which could possibly drastically improve the performance, with some drawbacks however.
• Fields also have read cache built-in so that subsequent entity loads will use the cache to load the field content. A module that does not use fields might not have it's own custom caching.
• There is still the generic overhead added by fields but work is ongoing to improve that situation in Drupal 8 and it might possibly be backported as well.

So a module isn't more performant just because it uses fields for storing data or not, there are many more factors and it also depends on how the site is configured.