A Guardrail Only Humans Enforce Isn’t One

· by · in

I queried a MongoDB collection this week that didn’t exist, because I’d mistyped the name. MongoDB didn’t tell me. I got zero documents back and spent a minute thinking the data was gone.

A woman DBA with a clipboard beside a gated navy cabinet that accepts only matching parcels, while a second view shows her frowning at open buckets filling with a mix of fish and oranges from a chute.

MongoDB was working as designed.

A SQL Server table can’t exist halfway. Before you can put a row in one, something has to declare its columns, its types, its constraints. Run a query against a table that doesn’t exist and SQL Server stops with Msg 208, Invalid object name.[1] MongoDB skips that step on purpose. A collection is just a named bucket for documents, and MongoDB creates it the first time you store data in it.[2] Until then, a find() against that name returns zero documents, the same as an empty collection. The result doesn’t tell me which one I hit.

I get the appeal. You don’t need a migration script before your first insert. You don’t need a DBA’s sign-off to add a field your app started sending last Tuesday. For a lot of workloads, that flexibility is the entire point of reaching for a document database in the first place.

By default, nothing stops two documents in the same collection from looking like they belong to entirely different systems.[2] Put a customer record in orders today with a total field. Put a customer record in orders tomorrow with a totalAmount field instead, and a shippingAddress that’s a string this time instead of last week’s object. MongoDB will take both, store both, and never once mention that they disagree. The constraint that would normally catch that, a column with a declared type, doesn’t exist to catch it, because nothing in the bucket has a declared shape to begin with.

Without a validator, the checking falls to whoever wrote the code that day: the application logic, the code review, and the tests, if anyone wrote tests for it. MongoDB does support validators, but they came late. Document validation arrived in version 3.2 at the end of 2015, more than six years after the first release in February 2009.[3][4] The $jsonSchema operator followed in 3.6, in late 2017.[5] Once a validator is in place, it rejects invalid writes by default.[6] You still have to add one to each collection yourself. Until you do, nothing is checked.

A guardrail that only works when nobody makes a mistake isn’t a guardrail. It’s hope.

None of this means MongoDB is the wrong choice for every job. Flexible, evolving document shapes are a real and common need, and plenty of teams use MongoDB well within that model. But “well within that model” means someone is doing, by hand and by habit, the job the database engine would otherwise do for them. That’s worth knowing before you pick the tool, not after the bucket fills up with fish and oranges you can no longer tell apart.

I wanted to know how often public MongoDB projects add a database validator, so I checked 200 repositories on GitHub. One had a validator. The method, its limits, and how each validation option behaves on MongoDB 8.0 and 9.0 are in Where MongoDB Schema Validation Actually Lives (available 2026-10-30).

Got a MongoDB (or SQL Server) footgun that bit you the same way? I’d enjoy hearing it on Bluesky or LinkedIn, or in the comments below.

References

  1. MSSQLSERVER_208 - Microsoft Learn. Documents error 208, “Invalid object name”, raised when the specified object cannot be found. ↩
  2. Databases and Collections - MongoDB documentation. States that MongoDB creates a collection when you first store data for it, and that by default documents in a collection do not share a schema. ↩
  3. MongoDB - Wikipedia. Gives the first release date as February 11, 2009. ↩
  4. Release Notes for MongoDB 3.2 - MongoDB documentation source. States that starting in 3.2, MongoDB can validate documents during inserts and updates, with rules set per collection. The first 3.2 patch release is dated January 12, 2016. ↩
  5. Release Notes for MongoDB 3.6 - MongoDB documentation source. States that MongoDB 3.6 adds the $jsonSchema operator for document validation. The first 3.6 patch release is dated December 26, 2017. ↩
  6. Schema Validation - MongoDB documentation. Describes validation rules as something you add to a collection, and states that by default MongoDB rejects inserts and updates that would produce an invalid document. ↩
Tags: , , ,