Firebase Firestore Enterprise Native Mode

# Firestore Enterprise Native Mode

This skill provides a complete guide for getting started with Firestore Enterprise Native Mode, including provisioning, data model, security rules, and SDK usage.

## Provisioning

To set up Firestore Enterprise Native Mode in your Firebase project and local environment, see [provisioning.md](references/provisioning.md).

## Data Model

To learn about Firestore data model and how to organize your data, see [data_model.md](references/data_model.md).

## Security Rules

For guidance on writing and deploying Firestore Security Rules to protect your data, see [security_rules.md](references/security_rules.md).

## SDK Usage

To learn how to use Firestore Enterprise Native Mode in your application code, see:
- [Web SDK Usage](references/web_sdk_usage.md)
- [Python SDK Usage](references/python_sdk_usage.md)

## Indexes

Indexes help improve query performance and speed up slow queries. For checking index types, query support tables, and best practices, see [indexes.md](references/indexes.md).


# Firestore Data Model Reference

Firestore is a NoSQL, document-oriented database. Unlike a SQL database, there are no tables or rows. Instead, you store data in **documents**, which are organized into **collections**.

## Document Data Model

Data in Firestore is organized into documents, collections, and subcollections.

### Documents
A **document** is a lightweight record that contains fields, which map to values. Each document is identified by a name. A document can contain complex nested objects in addition to basic data types like strings, numbers, and booleans. Documents are limited to a maximum size of 1 MiB.

Example document (e.g., in a `users` collection):
```json
{
  "first": "Ada",
  "last": "Lovelace",
  "born": 1815
}
```

### Collections
Documents live in **collections**, which are containers for your documents. For example, you could have a `users` collection to contain your various users, each represented by a document.
* Collections can only contain documents. They cannot directly contain raw fields with values, and they cannot contain other collections.
* Documents within a collection can contain different fields.
* You don't need to "create" or "delete" collections explicitly. After you create the first document in a collection, the collection exists. If you delete all of the documents in a collection, the collection no longer exists.

### Subcollections
Documents can contain subcollections natively. A subcollection is a collection associated with a specific document.
For example, a user document in the `users` collection could have a `messages` subcollection containing message documents exclusively for that user. This creates a powerful hierarchical data structure.

Data path example: `users/user1/messages/message1`

## Collection Group Support

A **collection group** consists of all collections with the same ID. By default, queries retrieve results from a single collection in your database. Use a collection group query to retrieve documents from a collection group instead of from a single collection.

### Use Cases
Collection group queries are useful when you want to query across multiple subcollections that share the same organizational structure.

For example, imagine an app with a `landmarks` collection where each landmark has a `reviews` subcollection. If you want to find all 5-star reviews across *all* landmarks, it would involve checking many separate `reviews` subcollections.