Drupal has built-in revisioning functionality for entities. When updating a node you may create a new revision to have some history of node changes and even revert to older or newer revisions so you may not worry about breaking your content because of saving wrong changes. There are a lot of contributed modules which extend revisioning functionality and provide new depending on it: for example, it’s possible to force the creation of new revision on each node edit and have moderation functionality so newer revisions will go live only after review.
Problem
To provide revisioning functionality for any entity type default field storage (Field SQL storage) which is used in most cases has built-in support for it as well. In the database you might notice tables which are usually called field_data_{field name} and field_revision_{field name} - the first one store field data for current revision, the second one stores field data for all revisions of the entity including current revision. In case you do not use revisioning (even if the used entity does not support revisioning at all!) field_revision_{field name} still stores current revision data which is the same as stored in the field_data_{field name}. For fieldable entities (for example nodes) most of the data in size meaning is usually stored in fields and as result about a half of the data’s size takes revisions data which is just a duplication of current revision data (stored in field_data_{field name}) in case revisioning is not used!
Solution
Field SQL norevisions module makes it possible to select entity types and bundles for which you will not use revisions, and for selected fields revisions data (field_revision_{field name} table) will not be saved at all. First of all, it saves database space. Furthermore, it decreases the number of SQL queries needed to save an entity to a database and as result increases performance when saving. So if you do not use revisioning (I’m sure there are entity types and/or bundles for which you will not use it) and have some problems with database size or frequently save (insert/update) fieldable entities to a database this module may be helpful for you.

Recommended branch of the module for use is 7.x-2.x. 7.x-1.x provided alternative storage backend for fields which is not 100% compatible with default storage, has no options to choose particular entity types/bundles, and also has some issues with some modules (for example Views so you have to patch it first) because they depend on default storage in some places. 7.x-2.x just alters default field storage and overrides its behavior just in a few places so you get much more compatibility with other modules.