Firexport / Blog

La edición que eliges al crear una base de datos de Firestore, Standard o Enterprise, no se puede cambiar después. Ahora que el modo nativo de la edición Enterprise está disponible de forma general (GA) desde abril de 2026, conviene empezar las apps nuevas en Enterprise. Con una condición: tú te encargas de los índices y del acceso de los clientes.

Por qué Enterprise es mejor opción por defecto

1. No se puede cambiar, así que empieza por la que menos te frena

La edición se fija al crear la base de datos y no cambia. Cambiarla supone mover los datos a una base nueva, volver a crear los índices y la configuración de TTL y de copias de seguridad, y publicar una versión de la app que apunte a la base nueva (guía de migración).

Por eso conviene empezar por el lado en el que es menos probable quedarse atascado. Lo que te frena en Standard son funciones como la búsqueda, la agregación o las uniones, que se esquivan migrando o reestructurando. Lo que te frena en Enterprise suele ser un índice que falta: lo despliegas sin tocar ni el código ni los datos.

2. El mismo código, más consultas

El modo nativo de Enterprise usa los mismos SDK de Firebase y las mismas consultas (operaciones Core) que Standard. where(), orderBy(), los listeners onSnapshot(), la caché sin conexión y las reglas de seguridad funcionan igual, y admite el emulador local, los activadores de Cloud Functions (2.ª gen.), las mismas regiones que Standard y el uso gratuito del plan Spark. La diferencia está en el orden: los documentos con el mismo valor de orden no se ordenan por ID, así que, si paginas con cursores, añade el ID del documento a tu orderBy.

Encima de eso están las consultas Pipeline. Lo que en Standard había que rodear pasa a ser una sola consulta.

La búsqueda de texto, la geoespacial y las actualizaciones y borrados en bloque (DML) pasaron a disponibilidad general en octubre de 2026. Eso sí, Pipeline hace lecturas puntuales: no tiene listeners en tiempo real ni modo sin conexión, y en Pipeline las reglas de seguridad solo entienden filtros simples que comparan un campo con una constante. Deja las listas de pantalla y las actualizaciones en vivo en consultas Core, usa Pipeline para búsquedas, agregaciones e informes, y ejecuta los Pipeline complejos en el servidor (Admin SDK, Cloud Functions).

3. Las lecturas con índice cuestan menos

Standard cobra por número de documentos; Enterprise, por los bytes leídos y escritos. Son los precios de us-central1 en noviembre de 2026.

• Lecturas: leer por ID un documento de hasta 4 KiB cuesta la sexta parte en Enterprise, y hasta 24 KiB cuesta lo mismo o menos. Las consultas pagan además la lectura del índice: con un resultado cuestan un tercio, y cuantos más resultados, más se acercan a un sexto.
• Escrituras: crear un documento de 1 KiB sale más barato en Enterprise con hasta 2 entradas de índice (0,78 US$ por millón) y más caro desde 3 (1,04 US$). Las actualizaciones que cambian un campo indexado cuestan 2 unidades por entrada modificada, así que se encarecen antes.
• Borrados: hasta el documento más pequeño cuesta 1 unidad (0,26 US$), así que siempre sale más caro que en Standard (0,10 US$).

Si tu app lee mucho más de lo que escribe, Enterprise sale más barato. Si escribe y borra mucho, haz primero estas cuentas con el tamaño de tus documentos y tu número de índices.

El precio: los índices y el acceso corren por tu cuenta

Standard solo ejecuta consultas que un índice puede servir. Cada campo recibe un índice automático, y una consulta que necesita un índice compuesto falla con un error que enlaza a su creación. Así, el coste de una consulta depende solo del número de resultados.

Enterprise no crea índices y ejecuta las consultas aunque no los haya. A cambio, lee la colección entera y cobra por los bytes leídos, y ordena en memoria, con lo que puede chocar con el límite de memoria por consulta (128 MiB). Como no hay error, no se nota mientras desarrollas con unas decenas de documentos; aparece cuando crecen los datos.

Esto cuesta ejecutar un millón de veces una consulta que busca a un usuario por su nombre de usuario. Los documentos pesan 2 KiB; la primera fila es el ejemplo de precios de Google y la segunda, el mismo cálculo con 100.000 documentos.

Un solo índice marca una diferencia de 25.000 veces en lo que cuesta la misma consulta (100.000 × 2 KiB ÷ 4 KiB = 50.000 unidades por consulta).

Esa diferencia también la puede usar otra persona. Si los clientes pueden listar una colección, cualquiera puede añadir un filtro sobre un campo sin índice y hacer que Firestore recorra todo lo que tiene permiso para leer. Como nada coincide, limit no sirve, y las reglas de seguridad no pueden bloquear un filtro añadido a una consulta. En Standard, esa consulta simplemente falla.

Cuatro hábitos

1. Escribe el índice cuando escribas la consulta. Por cada combinación de where y orderBy sobre una colección que sigue creciendo, añade un índice a firestore.indexes.json y despliégalo con firebase deploy --only firestore:indexes. Eso incluye los índices de un solo campo que Standard creaba por ti. Las lecturas por ID de documento no necesitan índice. Este es el índice para where('authorId', '==', uid).orderBy('createdAt', 'desc'):

   {
     "indexes": [
       {
         "collectionGroup": "posts",
         "queryScope": "COLLECTION",
         "fields": [
           { "fieldPath": "authorId", "order": "ASCENDING" },
           { "fieldPath": "createdAt", "order": "DESCENDING" }
         ]
       }
     ]
   }

2. Compruébalo con Query Explain antes de publicar. En la consola de Firebase, ejecuta la misma consulta en el editor de consultas (Query Editor) de la pestaña Datos (Data) de Firestore y abre la pestaña Query Explain. Si al fondo del árbol de ejecución aparece TableScan, se leyó la colección entera sin índice.
3. Acota el acceso de los clientes. Exige App Check para rechazar las solicitudes que no vengan de tu app, y usa reglas de seguridad para atar las lecturas de listas a una igualdad sobre un campo indexado, como resource.data.ownerId == request.auth.uid. Así, si alguien provoca un recorrido, se queda dentro de los documentos de ese usuario.
4. Activa Query Insights y las alertas de presupuesto. Query Insights muestra tus consultas frecuentes y su rendimiento, lo que te dice dónde falta un índice. En el plan Blaze, configura también una alerta de presupuesto de Cloud Billing.

Empezar en Enterprise

En la consola de Firebase, abre Firestore, haz clic en Crear base de datos (Create database), elige Enterprise y el modo nativo (Native mode), y define un ID y una ubicación. Deja activadas las actualizaciones en tiempo real (Realtime Updates), que vienen así por defecto. No se pueden cambiar después, y una base creada sin ellas no admite listeners. A partir de ahí, tres cosas son distintas de Standard.

1. Pasa el ID de la base de datos en tu código. Una base de datos Enterprise es una a la que tú le pones nombre; (default) solo existe en Standard. Los SDK se conectan a (default) salvo que les indiques otra.

   // Web
   const db = getFirestore(app, 'app-db');
   
   // Android (Kotlin)
   val db = FirebaseFirestore.getInstance("app-db")
   
   // iOS (Swift)
   let db = Firestore.firestore(database: "app-db")
   
   // Flutter
   final db = FirebaseFirestore.instanceFor(
       app: Firebase.app(), databaseId: 'app-db');

2. Indica la base de datos y la edición en firebase.json. Así las reglas y los índices se despliegan en esa base y el emulador arranca como Enterprise. Crea antes la base de datos en la consola. Si la base indicada no existe, firebase deploy la crea por ti, y Firebase CLI 15.12 la crea entonces en modo de compatibilidad con MongoDB, que los SDK de Firebase no pueden usar.

   {
     "firestore": {
       "database": "app-db",
       "edition": "enterprise",
       "rules": "firestore.rules",
       "indexes": "firestore.indexes.json"
     }
   }

3. El uso gratuito va a la primera base de datos que crees, y solo a esa. Si el proyecto tiene una base Standard que no usas, bórrala antes de crear la Enterprise, para que el uso gratuito pase a Enterprise.

Cuándo Standard sigue siendo mejor

• Apps que ya funcionan en Standard. No migres hasta que de verdad necesites Pipeline.
• Proyectos sin nadie que cuide las consultas y los índices. Que Standard se niegue a ejecutar consultas sin índice es tu red de seguridad.
• Apps cuyos clientes leen directamente colecciones públicas grandes. En las listas públicas que las reglas no pueden acotar, cualquiera puede provocar un recorrido completo.
• Apps que escriben y borran mucho, o que leen sobre todo documentos grandes. Pasados los puntos de equilibrio de arriba, Standard sale más barato.
• Cuando necesitas herramientas que dan por hecha la base (default) o Cloud Functions de 1.ª gen. Las bases Enterprise tienen nombre propio y los activadores de 1.ª gen. no las admiten.

Fuentes

• Ediciones de Firestore, comparación de ediciones en modo nativo, descripción general del modo nativo de Enterprise: diferencias de funciones, índices, orden y recorridos
• Precios de Enterprise, ejemplos de precios de consultas, ejemplos de precios de escrituras y borrados, precios de Firebase: precios y uso gratuito
• Migrar de Standard a Enterprise, notas de la versión de Firestore
• Primeros pasos con Enterprise, administrar bases de datos, configuración de la base de datos (REST), ubicaciones, cuotas y uso gratuito
• Índices de Enterprise, formato JSON de índices, Query Explain, Query Insights
• Reglas de seguridad para Pipeline, App Check, activadores de Cloud Functions, emulador