Firebase Firestore — qué es, documentos y colecciones NoSQL

Qué es Firebase Firestore

Firebase Firestore es una base de datos NoSQL en la nube lanzada por Google en 2019 como sucesora de Realtime Database. Firestore está construido sobre la infraestructura de Google Cloud Spanner y Google Cloud Datastore, lo que proporciona una fuerte consistencia de datos dentro de una sola transacción y replicación multirregional automática. El SDK admite Android, iOS, Web (JavaScript), Flutter, Kotlin Multiplatform y Unity.

Evolución desde Realtime Database

Firestore fue anunciado en Google I/O 2017 como “Cloud Firestore” — una solución que aborda las limitaciones clave de Realtime Database: falta de soporte para consultas complejas, imposibilidad de escalar datos en múltiples nodos y consistencia débil. Según Google (2026), Firestore procesa más de 1 billón de solicitudes por día y es la base de datos predeterminada para el 80% de los nuevos proyectos de Firebase. Sin embargo, Realtime Database sigue siendo relevante para escenarios de latencia ultra baja (juegos, edición colaborativa) debido a su estructura JSON directa.

Límites gratuitos de Firestore

Firestore se ofrece con un modelo de pago por uso con un generoso límite gratuito en el plan Spark: 1 GB de almacenamiento, 10 GB de tráfico de red al mes, 50 mil operaciones de lectura, 20 mil operaciones de escritura y 20 mil operaciones de eliminación por día. En el plan Blaze, todo lo anterior es gratuito y los excesos se cobran: $0.06 por cada 100 mil operaciones de lectura, $0.18 por cada 100 mil operaciones de escritura. Según Google (2026), el 90% de los proyectos se mantienen dentro del límite gratuito.

Modelo de datos: colecciones, documentos y campos

El modelo de datos de Firestore está organizado jerárquicamente: la raíz contiene colecciones, cada colección contiene documentos, cada documento contiene campos (tipos primitivos, arrays, Map) y colecciones anidadas (subcolecciones). La profundidad de anidamiento de las colecciones es ilimitada, pero un documento no puede contener directamente otro documento, solo a través de una referencia (tipo Reference).

Colecciones y documentos

Una colección es un contenedor de documentos con identificadores generados automáticamente o definidos por el usuario. Cada documento es un objeto similar a JSON de hasta 1 MiB de tamaño. Los campos de un documento pueden ser cadenas, números, valores booleanos, arrays, Map, marcas de tiempo (Timestamp), GeoPoints y referencias a otros documentos (Reference). El tamaño del documento está limitado a 1 MiB, incluidos los nombres de todos los campos.

Escritura por lotes y transacciones

Firestore admite transacciones atómicas a nivel de base de datos. Una transacción puede leer y escribir varios documentos: Commit aplica atómicamente todos los cambios o ninguno. Máximo de 500 operaciones por transacción, tiempo de espera de 60 segundos. La escritura por lotes (batch write) es una operación atómica no transaccional de solo escritura sin fase de lectura. Las transacciones son críticas para operaciones financieras, reservas de asientos y gestión de inventario.

Comparación entre Firestore y Realtime Database

Elegir entre Firestore y Realtime Database depende de los requisitos del proyecto. Ambas bases de datos forman parte del ecosistema de Firebase, ofrecen sincronización en tiempo real y están disponibles en todas las plataformas, pero se diferencian fundamentalmente en el modelo de datos, el escalado y los precios.

Diferencias clave

Realtime Database almacena datos en un único árbol JSON, lo que es conveniente para estructuras simples, pero dificulta el escalado con anidamientos de más de 3 niveles. Firestore utiliza un modelo de colecciones y documentos con particionamiento automático, lo que permite escalar a millones de documentos sin degradación del rendimiento. Según Google (2026), Firestore admite hasta 10 mil conexiones simultáneas a una sola colección sin pérdida de velocidad, mientras que Realtime Database admite hasta 200 mil conexiones a una sola instancia.

Precios

Realtime Database se factura según el volumen de datos transferidos (bytes descargados) y el número de conexiones simultáneas. Firestore se factura por número de operaciones (lectura, escritura, eliminación). Para aplicaciones con actualizaciones pequeñas y frecuentes (chat, notificaciones), Firestore suele ser más rentable: cada operación de escritura tiene un precio fijo independientemente del tamaño de los datos. Para aplicaciones con lecturas poco frecuentes de grandes volúmenes de datos, Realtime Database puede ser más económico.

Recomendación de Google (2026): use Firestore como base de datos predeterminada para nuevos proyectos y Realtime Database para juegos y aplicaciones donde la latencia mínima (menos de 50 ms) y la estructura de datos plana sean críticas. Ambas bases de datos pueden funcionar simultáneamente en el mismo proyecto.

Consultas, índices y paginación en Firestore

Las consultas de Firestore se ejecutan en colecciones o grupos de colecciones con filtrado, ordenación y límites. A diferencia de Realtime Database, donde cada consulta recorre todo el árbol JSON con filtrado del lado del cliente, Firestore ejecuta todas las consultas en el servidor utilizando índices precreados. Esto garantiza que la complejidad de la consulta dependa solo del tamaño del resultado, no del tamaño de la colección.

Tipos de consultas

Firestore admite filtrado por uno o varios campos (igualdad, rango, in, array-contains, array-contains-any), ordenación ascendente y descendente, límites y cursores para paginación. Limitaciones: las consultas compuestas con filtrado en diferentes campos (where price > 10 AND where category == “books”) requieren un índice compuesto; las consultas OR están prohibidas (use in y array-contains-any en su lugar) y no se permiten consultas de desigualdad en diferentes campos.

data class Product(
    val name: String = "",
    val category: String = "",
    val price: Double = 0.0,
    val inStock: Boolean = false
)

suspend fun FirestoreRepository.queryProducts(): List<Product> {
    return firestore
        .collection("products")
        .whereEqualTo("category", "electronics")
        .whereGreaterThanOrEqualTo("price", 100.0)
        .whereLessThan("price", 500.0)
        .orderBy("price")
        .limit(20)
        .get()
        .await()
        .toObjects(Product::class.java)
}

Índices automáticos y compuestos

Firestore crea automáticamente índices para campos individuales: las consultas de un solo campo funcionan sin configuración alguna. Para consultas con dos o más campos (filtrado + ordenación), se requieren índices compuestos. Cuando se envía una consulta por primera vez, Firestore devuelve un error con un enlace a la consola donde se puede crear el índice con un clic. Máximo de 200 índices compuestos por base de datos. Los índices se pueden exportar e importar mediante Firebase CLI.

Integración de Firestore en Android

Conectar Firestore a una aplicación de Android se realiza de forma estándar a través de Firebase BOM. Después de agregar la dependencia firebase-firestore-ktx, el objeto FirebaseFirestore está disponible a través de getInstance(), sin claves ni tokens adicionales. Firestore utiliza el mismo proyecto de Firebase que los demás servicios.

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-firestore-ktx")
}

// Inicialización
val db = FirebaseFirestore.getInstance()

Lectura y escritura de datos

Firestore proporciona dos modos de lectura: única (get) y en tiempo real (addSnapshotListener). La lectura única recupera un documento una vez, útil para configuraciones y ajustes. Un listener se suscribe a los cambios: cualquier actualización de un documento entrega automáticamente los datos actualizados a todos los clientes conectados en tiempo real. set() crea o sobrescribe un documento, update() modifica solo los campos especificados sin sobrescribir todo el documento.

Según Google (2026), las aplicaciones de tamaño mediano (100 mil DAU) con Firestore en tiempo real consumen entre 5 y 10 GB de tráfico saliente al mes. El uso de la caché sin conexión (Persistence Cache) reduce las descargas repetidas entre un 60 y un 70 %, ya que el SDK solo carga los documentos modificados cuando se restablece la conexión.

Modo sin conexión

Persistence Cache es un mecanismo integrado de Firestore para trabajar sin acceso a Internet. El SDK almacena automáticamente en caché todos los documentos leídos en el dispositivo (hasta 500 MiB en Android). Cuando se pierde la conexión, las lecturas continúan desde la caché y las escrituras se ponen en cola. Cuando se restablece la conexión, todas las operaciones pendientes se envían al servidor y la caché se sincroniza con el servidor. Para el control de conflictos, use snapshot-metadata.hasPendingWrites y setOptions(ServerTimestampBehavior).

Reglas de seguridad y validación de datos

Security Rules es un lenguaje declarativo de control de acceso para Firestore que se ejecuta en el servidor de Google antes de cada operación de lectura o escritura. Las reglas no requieren código del lado del servidor: se escriben en la consola de Firebase o a través de Firebase CLI y se versionan mediante Git. Cada operación se verifica con las reglas y una infracción devuelve un error PERMISSION_DENIED.

Estructura de las reglas

Las Firestore Security Rules constan de bloques match y expresiones allow. match define la ruta a una colección o documento, allow especifica las operaciones permitidas (read, write, create, update, delete) y una condición, una expresión similar a JavaScript que devuelve un booleano. Las reglas pueden verificar la autenticación (request.auth), los datos de la solicitud (request.resource.data), los datos existentes (resource.data), la hora (request.time) y la ruta (request.path).

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read: if request.auth != null;
      allow write: if request.auth.uid == userId;
    }

    match /products/{productId} {
      allow read: if true;
      allow create: if request.auth.token.role == "admin";
      allow update: if resource.data.authorId == request.auth.uid;
    }
  }
}

Validación de datos

Security Rules admite la validación de tipos y valores en el lado del servidor. Puede prohibir la escritura si el precio es negativo o el nombre está vacío. Todas las comprobaciones se realizan en el servidor de Google antes de la escritura, lo que garantiza la consistencia de los datos independientemente del cliente (Android, iOS, Web, Admin SDK). Las reglas no protegen contra el Admin SDK malicioso, ya que omite las reglas por diseño. Para una protección completa, utilice Transaction Functions y Firebase Extensions.