Cuando hablamos de bases de datos NoSQL en Firebase, siempre sale la misma pregunta: ¿Cloud Firestore o Realtime Database (RTDB)? Las dos te ofrecen sincronización en tiempo real y son parte del ecosistema de Google, pero tienen diferencias bien marcadas. Yo las veo como dos herramientas para problemas distintos, y entender esas diferencias te ahorra hartos dolores de cabeza.
La verdad, al principio no entendía por qué Google sacó Firestore si ya tenía RTDB. Me parecía sobreingeniería. Pero después de un par de proyectos, especialmente con apps que escalaban, me di cuenta de que la cosa no era tan simple como parecía. La clave está en cómo modelas y consultas tus datos.
La estructura manda: JSON puro vs. Documentos y Colecciones
Para mí, la diferencia más grande es la estructura de los datos. RTDB es un árbol gigante de JSON. Es súper flexible, claro, pero te obliga a pensar en rutas y a veces a denormalizar tus datos de forma un poco brutal para que las consultas sean eficientes.
Firestore, en cambio, usa un modelo de documentos y colecciones. Tienes colecciones de documentos, y esos documentos pueden tener subcolecciones, que a su vez tienen más documentos. Es una jerarquía más formal, más parecida a cómo uno organiza archivos en carpetas.
Por ejemplo, en RTDB tendrías algo así:
{
"usuarios": {
"usuario123": {
"nombre": "Jorge",
"email": "jorge@1up.cl"
},
"usuario456": {
"nombre": "Ana",
"email": "ana@example.com"
}
},
"productos": {
"prodA": {
"nombre": "Laptop",
"precio": 1200
}
}
}
En Firestore, la misma estructura se vería más como:
// Referencia a una colección
db.collection("usuarios").doc("usuario123").get().then(doc => {
if (doc.exists) {
console.log("Datos del usuario:", doc.data());
}
});
// Para agregar un producto
db.collection("productos").add({
nombre: "Teclado Mecánico",
precio: 150,
stock: 20
});
Esa estructura de documentos y colecciones en Firestore me permite hacer algo que valoro mucho: consultas poco profundas. Cuando pido un documento, solo me trae ese documento, no toda la sub-estructura que tenga. Esto es clave si guardas datos anidados y no quieres descargar gigas de información cada vez.
Consultas: El gran diferenciador
Aquí es donde Firestore brilla y, para mí, justifica su existencia. Con RTDB, tus consultas son bastante limitadas. Básicamente, puedes ordenar por una propiedad y filtrar por otra, pero solo si ya estás en el nodo correcto. Si necesitas consultar por múltiples campos, te veías obligado a crear índices compuestos manuales o denormalizar la data a lo bestia, lo que me frustraba bastante.
Firestore, en cambio, tiene consultas mucho más potentes. Puedes hacer consultas complejas con múltiples cláusulas where(), encadenar orderBy(), y hasta paginar los resultados de forma nativa. De hecho, muchas veces, Firestore crea y mantiene los índices que necesitas automáticamente, o te dice qué índice crear cuando intentas una consulta compleja. Eso es un alivio, te lo juro.
Escalabilidad y Rendimiento
Google diseñó Firestore pensando en la escalabilidad global. Lo importante aquí es que tus consultas escalan según el tamaño del conjunto de resultados, no del conjunto de datos completo. Esto significa que, aunque tengas millones de documentos, si tu consulta solo devuelve diez, será rápida. RTDB, si bien escala bien para muchas aplicaciones, puede tener problemas de rendimiento si tu árbol JSON se vuelve muy grande y las consultas no están optimizadas.
Además, Firestore ofrece soporte multi-región. Esto significa que tus datos se replican en varios centros de datos de Google, dándote más fiabilidad y una consistencia fuerte. Con RTDB, esto es más limitado.
Cómo buscar datos y el modelo de precios
Ambas bases de datos soportan listeners en tiempo real para que tu app reaccione a los cambios al instante. Pero si solo quieres obtener datos una vez, Firestore tiene llamadas de tipo get() que funcionan mucho mejor que las once() de RTDB, que a veces me daban un poco de lata.
El modelo de precios es otro punto a considerar. RTDB cobra principalmente por almacenamiento y ancho de banda. Firestore cobra por el número de operaciones (lecturas, escrituras, eliminaciones) que realizas, además de almacenamiento y ancho de banda. Esto significa que, si tienes una aplicación con muchos usuarios y poca interacción con la base de datos por cada usuario, RTDB podría ser más barato. Pero si tu app hace muchas consultas o transacciones, o si necesitas flexibilidad en las consultas, Firestore puede ser más conveniente.
Ojo que he visto casos donde la gente se queja del costo de Firestore por el tema de las lecturas. Es cierto que hay que optimizar, pero es parte del juego. No se trata de leer todo el tiempo, sino lo necesario.
Mi recomendación concreta
Si me preguntas qué usaría yo hoy en día para un proyecto nuevo, mi respuesta es casi siempre
Prefiero la estructura de documentos y colecciones porque me da más orden y mejor control sobre las consultas. La capacidad de escalar bien y las consultas potentes son un game changer para cualquier aplicación que quiera ir más allá de lo básico. RTDB todavía sirve para cosas muy simples o aplicaciones donde el modelo de datos es realmente un árbol plano y no necesitas consultas elaboradas, pero para la mayoría de los casos de uso, Firestore es una herramienta mucho más robusta y flexible.
En mi experiencia, la pequeña complejidad inicial de entender el modelo de documentos de Firestore se compensa con creces en el largo plazo, sobre todo cuando tus necesidades de consulta se vuelven más sofisticadas. Así te evitas la sobreingeniería que implica tratar de hacer magia con un árbol JSON gigante.