Finding Incorrect Data Types with MongoDB Queries

Recently, we encountered an issue in our system where the internet connection speed was being stored incorrectly. Instead of always being saved as an integer, some values were stored as floating-point numbers (double).

This might sound small, but it led to inconsistent data and confusing behavior in our application.

The Background

Our field features.internetSpeed is supposed to represent internet speed in whole megabits per second. For example:

{
  "features": {
    "internetSpeed": 384
  }
}

However, during a review, we noticed that some listings had values like:

{
  "features": {
    "internetSpeed": 384.54
  }
}

This meant we had some records stored as doubles instead of integers.

Detecting the Problem

MongoDB stores numbers with a specific BSON type. Integers and doubles are different types. To confirm which records were affected, we used a query that checks the BSON type of the field:

{
  "features.internetSpeed": {
    "$type": 1
  }
}

Here’s what’s happening in this query:

• features.internetSpeed → the field we’re inspecting.

• $type: 1 → tells MongoDB to return only documents where this field is stored as a double.

By running this query, we quickly identified that 19 listings still had their internet speed saved as doubles although we stopped using this data type a while ago.

Why This Matters

Finding the affected documents by data type was crucial because:

• It allowed us to quantify the issue (exactly 19 listings).

• It gave us a clear target set for a migration script to fix.

• It ensured that we weren’t just guessing—we had verified data from the database itself.

Lessons Learned

• MongoDB $type is powerful: It’s not just about values, but about the underlying storage type.

• Type enforcement matters: Even if values look right, the wrong type can lead to subtle bugs.

• Monitoring data health: Queries like this should be part of regular audits when schema expectations change.

Conclusion

By leveraging MongoDB’s $type query operator, we were able to find all the records where the internet connection speed was incorrectly stored as a double. This gave us confidence to move forward with a migration, knowing we had full visibility into the scope of the problem.

Sometimes the fix starts not with code, but with asking the right question of the database.