Index specifications changed silently after upgrading Mongoose from 6.x to 7.x

Short answer

Yes — the behavior you describe is consistent with the Mongoose 7 change to the useCreateIndex default. Under Mongoose 6 the option defaulted to false, so schema-defined indexes were not automatically created unless you opted in. Under Mongoose 7 the default is true, so on startup Mongoose issues createIndex calls for every index declared in your schemas. If your v6-era collections only had manually created indexes, the upgrade silently adds (or alters) index specifications without any code change on your side.

Two important consequences:

• Setting useCreateIndex: false after the fact does not remove indexes Mongoose 7 already created. The option only controls whether Mongoose issues create commands going forward.
• To return to the pre-upgrade state you must explicitly drop the unwanted indexes and then control creation yourself.

How to confirm the root cause from observable state

Don't rely on the migration notes alone — verify all three of these:

1. Installed version: node -e "console.log(require('mongoose').version)" — confirm it starts with 7.. Also check your lockfile in case multiple versions are resolved.
2. Effective option value: at runtime, inspect mongoose.get('useCreateIndex') (or the connection options). If it is true and your codebase never sets it, the new default is in effect.
3. Actual index state: in the MongoDB shell, run db.yourCollection.getIndexes() on an affected collection and compare the output against (a) your schema's index() declarations and (b) any indexes you created manually. Indexes matching schema definitions that you never created by hand are the ones Mongoose 7 added.

If you want positive proof that Mongoose is issuing the commands, enable MongoDB profiling or check the server logs during application startup — you should see createIndexes commands arriving from your app host right after connection.

Restoring prior behavior

Decide which end state you want first:

• Keep Mongoose-managed indexes (recommended for most apps): leave the default as-is, but make it explicit — set useCreateIndex: true in your connection options so a future default change can't surprise you again. Review the newly created indexes with getIndexes() and confirm they match your schema intent.
• Return to manual index management: set useCreateIndex: false explicitly, then drop the indexes Mongoose 7 created: db.yourCollection.dropIndex("index_name") for each one identified in the comparison above. Do this in a staging environment first; dropping an index that queries depend on can cause immediate performance regressions.

Note that Model.init() or restarting the app with the option set to false will not clean up existing indexes — MongoDB indexes persist until explicitly dropped. A "reindex" is not required; only targeted drops of the auto-created specs.

Other v6 → v7 defaults worth auditing

The same class of silent drift can come from other changed defaults. Notably, strictQuery behavior changed across these major versions, affecting how unknown query filter fields are handled, and there were changes around versionKey handling and the removal of several deprecated options. The practical takeaway: audit every connection and schema option your app relies on implicitly, and pin them all explicitly in code. A quick way to start is to diff your effective options (mongoose.connection config plus schema options) between a v6 and v7 boot of the same codebase.

One caveat

This analysis assumes the index differences you see correspond to schema-declared indexes. If getIndexes() shows specs that match no schema definition and no manual creation script, something else (another service, a migration tool, an ODM plugin) is creating them — share one example of a differing index spec if that's the case, since it would change the recommendation.