# Field-name abbreviation trade-offs > Source-anchored research for Field-name abbreviation trade-offs. Run status: COMPLETED. Parent: [Schema Design for Storage Cost](https://llms-explorer.com/tree/schema-design-for-storage-cost/) · 7 facets · 15 facts · page: https://llms-explorer.com/tree/field-name-abbreviation-trade-offs/ ## Structure and components - BSON encodes each element with a type marker and a null-terminated field name. With values and structure unchanged, shortening a field name by k UTF-8 bytes saves k bytes per occurrence in ordinary uncompressed BSON; repeated occurrences in embedded documents multiply that saving. This byte-count rule is derived from the specification. (high confidence) — [source](https://bsonspec.org/spec.html) - MongoDB 7.0 data-modeling guidance says shortening field names does not reduce index size because those indexes have a predefined structure without field names. This guidance should not be generalized here to every specialized index representation. (medium confidence) — [source](https://www.mongodb.com/docs/v7.0/data-modeling/best-practices/) ## How it works - Names are repeated in each document, so shortening them matters most when names occupy a large fraction of the payload, including small documents or repeated embedded objects. (high confidence) — [source](https://www.mongodb.com/docs/v7.0/data-modeling/best-practices/) - Disk compression does not eliminate name bytes from uncompressed BSON in the database cache. Name shortening can therefore improve cache density even when compressed disk savings are modest; a latency improvement still requires workload measurement. (medium confidence) — [source](https://richardstartin.github.io/posts/shrinking-bson-documents) - Field-name abbreviation has its largest proportional effect when names occupy much of a document, such as small records or repeated embedded objects. MongoDB's documentation illustrates a nine-byte saving per document by replacing last_name with lname and best_score with score. (high confidence) — [source](https://www.mongodb.com/docs/v7.0/data-modeling/best-practices/) ## How-to and procedures - Prefer concise names that preserve meaning. Single-letter encodings make documents harder to understand and make index configuration harder to maintain. An application mapping can expose descriptive property names while storing shorter names, but that mapping becomes another maintained artifact. (high confidence) — [source](https://www.mongodb.com/company/blog/technical/difference-field-name-makes-reduce-document-size-increase-performance) ## Measurements and reference values - Percona's March 24, 2016 example reports BSON sizes of 54,879 and 41,392 bytes after abbreviating names, approximately a 24.6% reduction. These are Object.bsonsize measurements on one constructed document, not compressed disk measurements or a general savings percentage. (low confidence) — [source](https://www.percona.com/blog/2016/03/24/percona-how-to-field-names-and-document-size-in-mongodb/) - Allegro's January 14, 2021 MongoDB 4.4 experiment used one-million-document collections with compression enabled and measured storageSize minus freeStorageSize. Flattening and shortening user fields reduced the reported non-key portion from 3.4 MB to 2 MB. That comparison combines structural and naming changes and excludes the key portion; it does not establish a 41% reduction in the whole collection or isolate abbreviation alone. (low confidence) — [source](https://blog.allegro.tech/2021/01/impact-of-the-data-model-on-the-MongoDB-database-size.html) ## Problems, failure modes and limitations - Raw BSON savings cannot be equated with compressed disk savings. WiredTiger block compression exploits repeated field names, so MongoDB's compression article describes the additional disk benefit of short names as modest; independent engineering analysis likewise distinguishes cache-size incentives from compressed storage. (high confidence) — [source](https://www.mongodb.com/blog/post/new-compression-options-mongodb-30) - Evaluate abbreviation with representative records under the intended compressor: measure raw BSON separately from allocated and unused collection storage, and assess readability alongside savings. Published measurements concern specific datasets and cannot supply a universal break-even point. (medium confidence) — [source](https://www.mongodb.com/blog/post/new-compression-options-mongodb-30) ## Comparisons and alternatives - In Small Datum's December 26, 2014 two-billion-document experiment, the long-name/short-name database-size ratio was about 1.01 with WiredTiger zlib, compared with 1.53 for mmapv1. The deliberately tiny values and historical engines limit generalization. (low confidence) — [source](https://smalldatum.blogspot.com/2014/12/storage-overhead-for-attribute-names-in.html) - Removing JSON whitespace is different from shortening names: BSON stores structure, names, and typed values rather than JSON formatting whitespace. Abbreviating a name changes encoded bytes; pretty-print removal alone does not. (high confidence) — [source](https://bsonspec.org/spec.html) ## Facts and statements - Cryptic single-letter names reduce expressiveness. An application mapping can retain descriptive application names while storing abbreviations, but operators still encounter the abbreviated database schema. (medium confidence) — [source](https://www.percona.com/blog/percona-how-to-field-names-and-document-size-in-mongodb/) - A defensible abbreviation evaluation profiles name-byte overhead and compares representative original and shortened documents. It then measures compressed storage and cache or workload behavior separately; raw BSON savings alone do not establish infrastructure savings. This is a synthesis of the format and experimental methods. (medium confidence) — [source](https://bsonspec.org/spec.html) - Shorter BSON documents can let more documents fit in cache and reduce uncompressed application payload size. The sources do not establish a universal latency improvement or a fixed storage-bill reduction from abbreviating names. (medium confidence) — [source](https://www.mongodb.com/company/blog/technical/difference-field-name-makes-reduce-document-size-increase-performance)