Sí: Firenook es un reemplazo directo y open source del Firebase Emulator oficial, escrito en Rust y sin Java, que lee tu firebase.json y usa los mismos puertos. Instalamos la versión 0.2.1 y la enfrentamos al Firebase Local Emulator Suite de Google en la misma máquina. La gran diferencia no está en las escrituras, sino en las consultas y en la memoria cuando tus datos crecen.
yoDEV Tested · 6 de noviembre de 2026
Probamos Firenook 0.2.1 frente a firebase-tools 15.35.0 (Firestore Emulator v1.22.0, OpenJDK 21) con Node 22.23.4 en Linux x64, 2 vCPU y 7 GiB de RAM. Los resultados que reportamos como nuestros salen de esa prueba.
¿Qué es Firenook y qué reemplaza del Firebase Emulator?
Firenook emula en local Firestore, Authentication, Cloud Storage, Cloud Functions, Pub/Sub, Cloud Tasks, Eventarc y Extensions, en los mismos puertos por defecto que la suite oficial (Firestore 8080, Auth 9099, Storage 9199, Functions 5001). Mantiene el formato oficial de importación y exportación, así que puedes volver al emulador de Google cuando quieras. Los servicios corren como código nativo dentro de un único paquete de npm, y no descarga nada más ni al instalar ni al arrancar.
Es un proyecto independiente con licencia Apache-2.0: no lo hace Google y no está afiliado ni respaldado por Google. Antes se publicaba como Fireside (@fireside-dev/cli); desde la 0.2.0-next.1, todas las versiones salen como firenook. Según npm, la 0.2.0, que el README presenta como la primera versión estable, se publicó el 23 de octubre de 2026. Ni el sitio ni los metadatos de npm nombran a una persona responsable, solo a la organización firenook-dev.
¿Cuánto más rápido que el Firebase Emulator oficial, según el proyecto?
Según su propio benchmark, unas 40 veces en escrituras y con 10 veces menos memoria. El proyecto reprodujo dos horas de tráfico de una aplicación en producción (211.205 documentos de Firestore y 6,7 GB en Storage) contra cada emulador por turnos, en un mismo servidor con un Ryzen 5 3600 y 64 GiB de RAM:
| Métrica (mediana) | Oficial | Firenook |
|---|---|---|
| Memoria máxima | 22,6 GiB | 2,11 GiB |
| Escritura | 208 ms | 5,1 ms |
| Actualización de listener | 209 ms | 11 ms |
| Reinicio conservando datos | 30,8 s | 0,59 s |
| CPU en dos horas | 1.586 s | 616 s |
Son cifras autorreportadas. Las muestras en bruto están publicadas en GitHub, pero la aplicación y sus datos son privados, así que nadie puede repetir exactamente esa prueba.
Hay un detalle de esa página que importa más que el titular: cuando empezaron las dos horas, el stack oficial ya tenía 7,7 GB en swap, y paginó 3,1 GB más durante la prueba. El propio proyecto reconoce que en una máquina con más memoria el emulador oficial usaría menos swap. Parte de esa diferencia de 40 veces en escrituras se explica porque el emulador oficial trabajaba bajo presión de memoria, no solo porque su motor sea más lento.
El resultado más convincente del proyecto no depende del swap. Con 2,7 millones de documentos, el emulador oficial se quedó sin memoria con la configuración por defecto de Java. Con un heap de 24 GiB sí arrancó, pero tardó entre 8 y 27 segundos en responder consultas del tipo orderBy … limit 20. Firenook respondió las mismas consultas en 3 a 6 ms.
¿Qué medimos al compararlo con el Firestore Emulator?
Ejecutamos el mismo script de Node con firebase-admin contra cada emulador, en la misma máquina: escrituras secuenciales de documentos y luego 50 ejecuciones de una consulta (array-contains + orderBy descendente + limit 20).
| Medida | Oficial | Firenook |
|---|---|---|
| Arranque en frío (Firestore + Auth) | 8,4 s | 0,53 s |
| Escritura, mediana, 20.000 docs | 0,89 ms | 0,94 ms |
| Escritura, p99, 20.000 docs | 4,67 ms | 3,43 ms |
| Consulta, mediana, ~2.000 docs | 18–20 ms | 3,8 ms |
| Consulta, mediana, ~20.000 docs | 168,7 ms | 3,4 ms |
| Memoria del emulador, ~4.000 docs | ~500 MiB (Java + Node) | 41 MiB |
| Memoria del emulador, ~20.000 docs | 658 MiB | 111 MiB |
| Reinicio con 20.000 docs conservados | — | 0,54 s, los 20.000 intactos |
Tres conclusiones:
- Con pocos datos y sin presión de memoria, las escrituras empatan. No reprodujimos la cifra de 40 veces en escrituras. Espérala solo si tu emulador oficial está usando swap.
- Donde se nota es en las consultas. Al pasar de 2.000 a 20.000 documentos, el emulador oficial se volvió unas diez veces más lento, mientras que Firenook se mantuvo estable. Con 20.000 documentos, la diferencia fue de unas 50 veces.
- La memoria es siempre entre cinco y diez veces menor, y Firenook arranca en medio segundo.
¿Cómo se instala y cómo reemplaza a firebase emulators:start?
Necesitas Node 22, 24 o 26 en macOS, en Linux x64 o arm64 con glibc 2.28 o superior, o en Windows x64. Instálalo como dependencia de desarrollo y conserva firebase-tools para hacer deploy, porque Firenook no tiene comandos de deploy ni de login:
npm install --save-dev firenook
Primero revisa tu proyecto actual. La simulación no escribe nada:
npx firenook init --adopt --dry-run
En nuestra prueba, el plan omitió el emulador de Realtime Database con un aviso y ofreció crear un .mcp.json para Claude Code. Después cambia los comandos en los scripts de tu package.json. Los flags habituales (--only, --project, --import, --export-on-exit, --inspect-functions) funcionan igual:
"scripts": {
"emulators": "firenook emulators:start --import ./data --export-on-exit",
"test:integration": "firenook emulators:exec \"npm test\""
}
En nuestra prueba, init --adopt no reescribió los scripts existentes, así que ese cambio lo haces tú. Agrega también .firenook/ a tu .gitignore: ahí guarda Firenook los archivos de trabajo de cada ejecución, y nunca los borra automáticamente.
¿Cómo conservar los datos entre ejecuciones del emulador?
Sustituye --export-on-exit por --keep-data y mantén --import ./data en el comando:
npx firenook emulators:start --import ./data --keep-data
En nuestra prueba, reiniciar con 20.000 documentos tardó 0,54 segundos, y todos los documentos seguían ahí.
Ojo con un detalle de la 0.2.1, que el proyecto lista entre sus problemas conocidos: --keep-data exige tener configurados Firestore, Auth y Storage. Con solo Firestore y Auth, nuestro arranque falló con --resume-state requires the firestore, auth and storage services. Lo resolvimos agregando el emulador de Storage al firebase.json.
¿Qué no emula Firenook todavía?
En la versión 0.2.1, al 6 de noviembre de 2026:
- No se emulan en absoluto: Realtime Database, Hosting, App Hosting, Data Connect y las extensiones universales. Un
firebase.jsonque los configure arranca igual, con un aviso. - Cloud Functions: no hay funciones en Python ni en Dart, ni Secret Manager.
functions:shellse sustituye porfirenook functions:invoke. - Auth: no hay multifactor TOTP, ni aplicación de reCAPTCHA, ni envío real de correos o SMS.
- Pub/Sub y Cloud Tasks: los datos no sobreviven a un reinicio.
- Plataformas: no hay soporte para Alpine/musl (lo que descarta muchas imágenes base de Docker), Windows en Arm ni Windows de 32 bits.
- Consola: la Emulator UI de Google se reemplaza por la consola propia de Firenook en el mismo puerto (
http://127.0.0.1:4000/console).
Si tu proyecto depende de Realtime Database o de funciones en Python, hoy Firenook no puede reemplazar a la suite oficial.
¿Se puede usar con Claude Code, Cursor o VS Code?
Sí. npx firenook mcp add configura un servidor MCP para Claude Code, Cursor o VS Code, y init --adopt se ofrece a escribir el .mcp.json de Claude Code por ti. Así un agente tiene acceso directo a los emuladores locales mientras escribe y prueba código de Firebase.
¿Vale la pena cambiar de emulador de Firebase?
Sí, si tu Firestore Emulator consume gigabytes de RAM, tarda segundos en responder consultas sobre un conjunto de datos realista o te obliga a instalar Java en cada runner de CI: en ese caso, Firenook merece una tarde de prueba. El cambio es reversible: npx firenook emulators:export ./export exporta en el formato oficial, y la CLI oficial arranca desde esa exportación. Eso sí, nunca ejecutes los dos en los mismos puertos ni en el mismo directorio de trabajo.
Si tu cuello de botella es la latencia de escritura con pocos datos, no notarás mucho. Y ten en cuenta que es un proyecto joven, en la 0.2.x y sin un responsable con nombre: haz commit de tu lockfile y actualiza de forma deliberada, como recomienda su propia documentación.
¿Y tú? ¿Cuánta memoria consume hoy el Firebase Emulator en tu máquina o en tu CI?
- Con el Firebase Local Emulator Suite oficial
- Ya probé Firenook
- No emulo: pruebo contra un proyecto real
- Prefiero otra opción (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.
Relacionado: El crash de Firebase en iOS: qué pasó y por qué desactivar Analytics no protegió tu app