A schema specifies the fields, structures, and data types that stored documents may contain. MongoDB permits documents in one collection to use different fields and types, so each document can carry its own structure. Flexibility supports evolving requirements and structured, unstructured, or semistructured data, but thoughtful modeling remains essential for query efficiency, scalability, and maintainability. section 5.0
Apply schema design by connecting structure to application behavior:
- Model relationships between data entities and shape fields around the application's query patterns. section 5.0
- Add validation when an established application requires predictable fields, formats, or data types. section 5.4
- Review Atlas schema suggestions when nested structures, large arrays, inconsistent types, missing indexes, or high-cardinality filters affect performance. section 21.2.2
Validation rules for operational data
A users collection can require password to remain a string. A flight-routes collection can require flight_id to match an FL-plus-numbers format, airline.id to be a positive integer, and source and destination airport codes to identify actual airports. An airport collection can require total_flights to be an integer. These rules preserve expected application meaning without removing MongoDB's general schema flexibility. section 5.4
Figure 18.1 Atlas SQL interface architecture (Image © MongoDB 2024 CC BY-NC-SA 3.0)
Use the Atlas SQL interface architecture to trace how federated databases, virtual collections, SQL drivers, named connectors, and BI tools interact. Atlas Data Federation generates JSON-based schemas by sampling collection documents for SQL compilation and type inference. section 18.1
