Si alguna vez te has quedado mirando tu consola de Firestore preguntándote '¿dónde puse esos datos?' o '¿por qué esta consulta no funciona?', no estás solo. Firestore es poderoso, pero su naturaleza NoSQL confunde a la mayoría de los desarrolladores — especialmente a quienes vienen de bases de datos SQL. Desglosemos exactamente por qué es confuso y qué puedes hacer al respecto.

Por Qué Firestore Se Siente Tan Diferente

Si has usado MySQL, PostgreSQL o cualquier base de datos SQL, has entrenado tu cerebro para pensar en tablas, filas y joins. Firestore desecha todo eso. No hay tablas — solo colecciones. No hay filas — solo documentos. No hay joins — solo datos desnormalizados. Y no hay imposición de esquema — documentos en la misma colección pueden tener campos completamente diferentes.

El cambio de modelo mental:

SQL

Tablas con columnas fijas → Las filas siguen un esquema estricto → JOINs combinan datos relacionados → La normalización evita duplicación

Firestore

Colecciones con documentos flexibles → Cada documento puede diferir → No hay JOINs — desnormaliza en su lugar → La duplicación es esperada y fomentada

5 Errores que Todo Principiante de Firestore Comete

1. Intentar normalizar todo

En SQL, normalizas para evitar duplicación de datos. En Firestore, esto te fuerza a hacer múltiples lecturas para ensamblar una sola vista. En su lugar, almacena los datos donde los lees — incluso si significa duplicar el nombre de usuario en cada comentario que escriben.

2. Usar arrays para relaciones

Almacenar un array de IDs de usuario en un documento parece lógico, pero los arrays de Firestore tienen limitaciones severas: no puedes consultar elementos individuales eficientemente, y no escalan más allá de unos miles de elementos. Usa subcolecciones o una colección separada con referencias en su lugar.

3. Poner todo en un documento

Firestore cobra por lectura de documento, así que es tentador meter todo en un gran documento. Pero los documentos tienen un límite de 1 MB, y leer un documento de 500 KB cuando solo necesitas 2 campos desperdicia ancho de banda y aumenta costos. Divide en documentos más pequeños y enfocados.

4. Ignorar las limitaciones de consulta desde el principio

Firestore no puede hacer filtros de desigualdad en múltiples campos en una sola consulta, no puede hacer búsqueda de texto completo nativa y requiere índices para consultas compuestas. Diseña tu modelo de datos alrededor de tus consultas desde el día uno — no al revés.

5. No documentar la estructura

Sin un esquema, tu base de datos Firestore se convierte en una caja negra. Los nuevos miembros del equipo adivinan nombres de campos, errores tipográficos causan bugs silenciosos, y nadie sabe si un campo es requerido u opcional. Este es el error más común y más dañino.

Cómo Dar Estructura a Tu Base de Datos Firestore

La buena noticia: puedes agregar estructura a Firestore sin renunciar a su flexibilidad. Aquí hay tres pasos prácticos:

1Diseña tus consultas primero

Antes de crear colecciones, lista cada pantalla en tu app y qué datos necesita. Este enfoque de consultas primero asegura que tu modelo de datos sirva a tu interfaz — lo opuesto al pensamiento SQL donde diseñas tablas primero.

2Usa nombres de campo y tipos consistentes

Decide convenciones temprano: ¿camelCase o snake_case? ¿Timestamps como Timestamps de Firestore o strings ISO? ¿Campos requeridos vs opcionales? Escribe estas decisiones en algún lugar donde tu equipo pueda encontrarlas.

3Documenta tus colecciones con JSON Schema

JSON Schema es un estándar abierto que te permite describir la estructura de cada colección: nombres de campos, tipos, cuáles son requeridos, qué valores son válidos. Es como un plano de tu base de datos — y funciona como documentación que se mantiene precisa si la guardas en tu repositorio.

Cómo Se Ve Esto en la Práctica

Aquí hay un JSON Schema simple que describe una colección users de Firestore. Nota cómo cada campo tiene un tipo y descripción — cualquiera en tu equipo puede entender el modelo de datos de un vistazo:

schemas/users.schema.jsonJSON

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "collection": "users",
  "description": "Registered app users",
  "schema": {
    "type": "object",
    "properties": {
      "displayName": {
        "type": "string",
        "description": "User's full name"
      },
      "email": {
        "type": "string",
        "format": "email",
        "description": "Login email address"
      },
      "role": {
        "type": "string",
        "enum": ["admin", "editor", "viewer"],
        "description": "Access control role"
      },
      "createdAt": {
        "type": "string",
        "format": "date-time",
        "description": "Account creation timestamp"
      }
    },
    "required": ["displayName", "email", "role", "createdAt"]
  }
}

Este archivo de esquema vive en tu repositorio, se revisa en PRs y sirve como la única fuente de verdad para tu colección users. Sin más adivinanzas.

Convierte Esquemas en Documentación Interactiva

Una vez que tengas archivos de esquema para tus colecciones, herramientas como FireSchema pueden renderizarlos como documentación interactiva y navegable — similar a cómo Swagger UI funciona para APIs REST, pero diseñado para bases de datos NoSQL. Es gratis, open-source y toma unos 5 minutos configurarlo.

Siguientes Pasos

Continúa construyendo tu conocimiento de Firestore:

Por Qué Firestore Es Confuso (Y Cómo Arreglarlo)