Variety: MongoDB schema analysis with mongosh

Why Variety fits inherited MongoDB collections

MongoDB documents can evolve without a fixed table-like schema, especially when applications have accumulated legacy fields or write different field shapes over time. Variety addresses discovery rather than enforcement. The README positions it for engineers who inherit a codebase and data dump and need to understand how documents are structured without reading every record by hand.

Its output makes uncommon fields easy to identify. A count and percentage are reported for each key, so a field present in five documents can be distinguished from one present in thousands. This makes Variety useful for locating rare keys that may represent abandoned prototypes, conditional application behavior, or incomplete migrations. It also exposes type inconsistency. In the documented example, `pets` appears as both `String` and `Array`, while `someWeirdLegacyKey` occurs in only one of five documents.

The intended users are developers and database engineers working directly with MongoDB through a shell. Variety does not present itself as an application runtime dependency or a data-model validator. Its job is to describe observed collection contents. That boundary matters because a low-frequency type can still be valid, while a high-frequency field can still reflect an unintended schema decision.

How Variety turns documents into a type inventory

The README shows Variety operating as a JavaScript program inside a MongoDB shell. The command selects a database, assigns a global `collection` variable, and passes `variety.js` to `mongosh`. The resulting table lists each discovered key, its observed types, the number of documents containing that key, and the corresponding percentage.

The example demonstrates the distinction between a field and its possible representations. `pets` does not resolve to one universal label. Variety reports `String (1),Array (1)` and an occurrence count of two across the five inserted documents. This is more useful for initial investigation than a guessed schema because it retains the evidence of variation rather than normalizing it away.

Variety can restrict which documents are scanned with `limit`. The README states that this selects the newest documents unless another sort is used. It therefore changes occurrence counts and percentages. That option is separate from `maxExamples`, which controls how many example values are collected for output and does not change which documents are scanned. This separation prevents a display setting from silently changing the analyzed population.

The documented type inventory is broad but intentionally normalized. Variety maps all storage-level BSON value categories into output labels such as `Number`, `Code`, `String`, `DBRef`, and subtype-specific `BinData-*` labels. Standard binary subtypes, user-defined binary subtypes, and vector payload dtypes receive documented handling. The label set is therefore designed for readable analysis rather than reproducing every BSON type name verbatim.

Running the first collection analysis

The README does not provide package installation steps or an npm installation command. It presents the shell script as `variety.js`, and the repository package metadata lists `variety.js` as the package main file and `bin/variety` as its executable entry. Following the documented example requires the MongoDB database and collection to exist first.

The README creates a `users` collection by inserting several deliberately inconsistent documents, then starts Variety through `mongosh`. This command passes the `test` database, defines the collection name, and loads the analyzer:

$ mongosh test --eval "var collection = 'users'" variety.js

For a populated collection, the expected output is a table containing keys such as `_id`, `name`, `bio`, `birthday`, `pets`, and rare fields. Every listed occurrence percentage is calculated against the analyzed documents. For the five-document example, `name` appears in 100.0 percent and `someWeirdLegacyKey` in 20.0 percent.

Variety prints to standard output by default. Environments that still use the legacy `mongo` shell can substitute that executable in the command. The shell choice matters because the README associates `mongosh` with MongoDB 6.0 and later, and `mongo` with MongoDB versions below 6.0.

Limiting recent documents without changing example output

A large collection can make the question more useful if the goal is to inspect current document shapes rather than all historical records. Variety exposes `limit` for this purpose. The documented command analyzes only the newest document because no alternative sort is specified:

$ mongosh test --eval "var collection = 'users', limit = 1" variety.js

With `limit = 1`, the result describes one document rather than the full collection. Its percentages therefore describe that selected sample, not the collection's lifetime distribution. This is appropriate for checking recent structure, but it can hide a legacy key that appears only in older documents. An engineer looking for migration debris should not infer absence from a recent-only result.

Variety also has a `maxExamples` control, according to the README. That setting affects how many sample values are displayed for each key. It does not restrict the documents scanned. Confusing these controls could produce a misleading investigation, especially when a report is intended to establish how widespread a field is. The selection criteria and collection sort need to be stated whenever the results are saved or shared.

There is another operational limitation. Variety does not print a progress bar or completion percentage. The README directs users to MongoDB server logs for progress, although some MongoDB versions and logging configurations do not expose a percentage. A quiet client can therefore mean that progress reporting is unavailable, not necessarily that analysis has stalled.

Saving and interpreting analysis output

Standard output is the default delivery mechanism, which keeps simple inspection independent from an application. The README also points to a section titled "Save Results in MongoDB For Future Use" for retaining results in MongoDB. The README does not include the configuration or commands from that section, so no storage procedure can be reproduced safely from the documented text.

Interpretation still requires care. Variety reports what is present in the selected documents, but it does not say whether a rare field is obsolete or whether two types are compatible application states. For example, a `pets` value that is sometimes a `String` and sometimes an `Array` establishes variation, but deciding whether that variation violates a business rule requires application context. The analyzer narrows the investigation; it does not resolve it.

The same caution applies to percentages. They are most meaningful when the analyzed population is known. A full collection, a newest-document limit, and a sorted subset can produce different answers for the same key. Variety's support for custom sorting is referenced by the README, but the README does not show the complete syntax. Analysts should therefore preserve the exact shell variables used with a saved report.

Compatibility, maintenance, and licensing

The README lists MongoDB 8.2.x, 8.0.x, 7.0.x, and 5.0.x as tested release lines. For shells, it associates `mongosh` with MongoDB 6.0 and later and `mongo` with MongoDB below 6.0. Its Node.js table names the latest 22.x line and a latest 24.x smoke test. These are documented compatibility claims, not evidence about every MongoDB or Node.js release.

The repository was not archived, and its last push was on 2026-08-20. The repository has no GitHub releases, so there is no release cadence to infer from published GitHub release entries. Package metadata identifies the current package version as `1.5.2`, but it does not provide a dated migration plan for future versions.

The project is distributed under the MIT License. That permissive license is relevant when deciding whether the script can be incorporated into internal workflows or redistributed, but this review does not interpret the license text as legal advice. The package manifest also exposes a `variety` binary in addition to the shell script, although the README example uses `variety.js` directly with `mongosh`.

Variety versus manual mongosh exploration

Manual exploration through `mongosh` is the direct alternative. A database operator can query sample documents, inspect individual keys, or write custom aggregation expressions for a narrowly defined question. That approach leaves complete control over the query and the shape of the output, but the engineer must design the aggregation, count field presence, group observed BSON representations, and format the results.

Variety packages that investigation into a repeatable schema-oriented report. Its advantage is not a broader data model. It is a ready-made presentation for key presence, observed types, counts, and percentages across a selected set of documents. That makes it more suitable than an ad hoc query when the immediate goal is to identify inconsistent fields or rare keys.

The trade-off is reduced transparency into arbitrary analysis logic. When a question requires nested arrays, conditional application rules, sampling methodology beyond the documented controls, or a custom aggregation pipeline, direct `mongosh` work may be clearer. Variety is the better fit for the first inventory pass. It is less suitable as the sole tool for proving application invariants or diagnosing every record-level anomaly.

Editorial conclusion

Adopt Variety when you need a compact inventory of field types and their frequency in a MongoDB collection, especially after inheriting an unfamiliar data dump. Do not treat its output as a schema contract or replace application validation with it. Verify first that your shell version, MongoDB version, permissions, and analysis scope match the deployment you intend to inspect.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. variety/variety on GitHub