Firebase Realtime Database: qué es, estructura JSON y sincronización

Qué es Firebase Realtime Database

Firebase Realtime Database es una de las primeras bases de datos en la nube en tiempo real, lanzada por Google junto con Firebase en 2012. Es una base de datos NoSQL donde los datos se almacenan como un único árbol JSON accesible a través de una sola URL. Los SDKs de cliente (Android, iOS, Web) se suscriben a nodos específicos del árbol mediante WebSocket y reciben actualizaciones en cada cambio de datos — sin necesidad de hacer polling al servidor ni implementar un mecanismo Push personalizado.

Historia y Desarrollo

Firebase original fue fundada en 2011 por James Tamplin y Andrew Lee, y el primer producto fue precisamente Realtime Database. Tras la adquisición por Google en 2014 (según TechCrunch — por una cantidad entre 50 y 100 millones de dólares), la base de datos se integró en Google Cloud y recibió un rendimiento significativamente mayor. En 2017, Google anunció Firestore como un reemplazo evolutivo, pero Realtime Database sigue siendo compatible y actualizado activamente. Según Google (2026), Realtime Database todavía se utiliza en más de 1.5 millones de proyectos activos.

Límites Gratuitos y Precios

Plan Spark (gratuito) incluye: 1 GB de almacenamiento, 10 GB de datos descargados al mes, 100 conexiones simultáneas y soporte de base de datos en una región. En el plan Blaze (pago por uso), se cobra por almacenamiento adicional ($1/GB), tráfico ($0.12/GB) y conexiones simultáneas ($5 por cada 100 mil por encima del límite). Para pruebas, también está disponible el modo de emulación — firebase emulators:start — que ejecuta Realtime Database localmente sin conexión a la nube.

Estructura de Datos: Árbol JSON y Normalización

Realtime Database no tiene tablas, colecciones ni documentos — todo es un único árbol JSON accesible mediante una URL como https://project-name-default-rtdb.firebaseio.com/. Cada clave del árbol es o un valor final (cadena, número, booleano, null) o un nodo anidado con claves hijas. El motor de la base de datos no soporta JOIN, subconsultas ni agregaciones — una consulta siempre devuelve el contenido de un nodo con todos sus elementos hijos.

Normalización de Datos

Debido a la falta de JOIN en Realtime Database, la normalización de datos es obligatoria. En lugar de un árbol anidado (usuario → lista de sus publicaciones), los datos se dividen en listas planas con referencias a través de claves. Este es el enfoque estándar: los datos se desnormalizan para que la lectura de un nodo no extraiga todo el contexto. Por ejemplo, la lista de mensajes del chat se almacena separada de los perfiles de usuario, y cada publicación contiene solo el ID del autor, no todo su perfil.

Consultas en Realtime Database

Las consultas en Realtime Database se realizan utilizando filtros (orderByChild, orderByKey, orderByValue, limitToFirst, limitToLast, equalTo, startAt, endAt). A diferencia de Firestore, los índices se crean manualmente mediante la sección Rules (.indexOn). Si no se declara un índice, una consulta con ordenación devuelve un error PERMISSION_DENIED. Las consultas funcionan solo en un único campo — las consultas compuestas (filtrar por precio + ordenar por fecha) no son compatibles. Para filtrados complejos, los datos a menudo se duplican en diferentes nodos con diferentes claves de ordenación.

Realtime Database vs Firestore: Cuál Elegir

Elegir entre Realtime Database y Firestore es una de las decisiones arquitectónicas más comunes al iniciar un proyecto. Google recomienda Firestore para la mayoría de las nuevas aplicaciones, pero Realtime Database sigue siendo la mejor opción para escenarios donde la latencia mínima de transferencia de datos es crítica.

Tres Escenarios Clave para Realtime Database

Primer escenario — juegos multijugador con sincronización de estado (ajedrez, juegos de cartas, acción en tiempo real). La latencia de Realtime Database es de 10-30 ms frente a 50-100 ms de Firestore en una misma región. Segundo escenario — chats y mensajería con alta frecuencia de mensajes. Realtime Database se factura por volumen de datos, no por cantidad de escrituras, lo que lo hace significativamente más barato que Firestore en frecuencias superiores a 1 mensaje por segundo. Tercer escenario — presencia de usuarios (online/offline), donde los manejadores onDisconnect de Realtime Database permiten establecer atómicamente el estado al perder la conexión.

Según Google (2026), aproximadamente el 15% de los nuevos proyectos de Firebase eligen conscientemente Realtime Database — cuando el equipo comprende claramente sus requisitos de latencia, estructura de datos y presupuesto. En el 85% restante de los casos, Firestore es la opción más segura gracias a su mejor escalabilidad, consultas más potentes y replicación automática.

Integración de Realtime Database en Android

Conectar Realtime Database a una aplicación Android se realiza añadiendo la dependencia firebase-database-ktx en build.gradle. El objeto FirebaseDatabase está disponible mediante getInstance(url) — puedes conectarte a múltiples bases de datos dentro de un mismo proyecto Firebase. Tras la inicialización, el SDK establece automáticamente una conexión WebSocket con el servidor y comienza la sincronización de datos.

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

// Initialization with custom URL
val database = FirebaseDatabase.getInstance(
    "https://my-project-default-rtdb.firebaseio.com/"
)
val ref = database.getReference("chats")

Escritura y Lectura de Datos

Realtime Database utiliza el objeto DatabaseReference para todas las operaciones. setValue() escribe datos en el nodo especificado, reemplazando completamente todo su contenido. push() genera automáticamente una clave única (basada en una marca de tiempo) para añadir un elemento a una lista — esta es la forma estándar de crear mensajes de chat, publicaciones y registros. updateChildren() modifica múltiples nodos atómicamente en una sola operación. addValueEventListener se suscribe a los cambios de un nodo y recibe una callback en cada actualización de datos.

data class Message(
    val author: String = "",
    val text: String = "",
    val timestamp: Long = ServerValue.TIMESTAMP
)

class ChatRepository(private val ref: DatabaseReference) {
    fun sendMessage(author: String, text: String) {
        val msg = Message(author = author, text = text)
        ref.child("messages").push().setValue(msg)
    }

    fun observeMessages(): Flow<List<Message>> = callbackFlow {
        val listener = ref.child("messages")
            .addValueEventListener(object : ValueEventListener {
                override fun onDataChange(snapshot: DataSnapshot) {
                    val messages = snapshot.children.mapNotNull { it.getValue(Message::class.java) }
                    trySend(messages)
                }
                override fun onCancelled(error: DatabaseError) {}
            })
        awaitClose { ref.removeEventListener(listener) }
    }
}

Sincronización en Tiempo Real y Modo Offline

El mecanismo de sincronización de Realtime Database se basa en el protocolo WebSocket (anteriormente — long-polling). El cliente envía una solicitud para suscribirse a un nodo específico, y el servidor mantiene la conexión abierta. Ante cualquier cambio de datos en el nodo suscrito, el servidor envía el JSON completo de ese nodo al cliente. El SDK en el cliente actualiza automáticamente el estado local y ejecuta las callbacks correspondientes (onDataChange).

OnDisconnect — Disparadores de Desconexión

OnDisconnect es una característica única de Realtime Database que no está presente en Firestore. Un desarrollador puede registrar una operación de escritura que se ejecutará automáticamente en el servidor cuando se pierda la conexión del cliente. Esto se utiliza para estados de presencia: "user123/status": "online" con onDisconnect.setValue("offline"). Si el usuario cierra la aplicación o pierde internet, el servidor establecerá automáticamente el estado a "offline" en un máximo de 3 minutos (configurable en la consola de Firebase).

Caché Offline

Persistence en Realtime Database se habilita con una sola línea: FirebaseDatabase.getInstance().setPersistenceEnabled(true). El SDK almacena en caché el último estado de todos los nodos suscritos en el disco (hasta 10 MiB por defecto, configurable hasta 100 MiB). Cuando se pierde la conexión, el cliente continúa trabajando con los datos en caché, y todas las operaciones de escritura se ponen en cola. Cuando se restaura la conexión, el SDK envía todos los cambios acumulados al servidor en el orden correcto (FIFO).

Según Google (2026), las aplicaciones con caché de persistencia habilitada tienen un 40% menos de probabilidades de perder datos de usuario al perder la conexión. Sin embargo, si un cliente ha acumulado más de 1000 operaciones pendientes, el servidor puede rechazarlas todas y solicitar una sincronización completa — este es un mecanismo de protección contra clientes desactualizados.

Reglas de Seguridad y Validación

Las Reglas de Seguridad en Realtime Database son una configuración JSON que describe quién puede leer y escribir datos en cada nodo y bajo qué condiciones. Las reglas se ejecutan en el servidor de Google y se aplican antes de cada operación. Por defecto (en producción), se recomienda configurar las reglas en modo "cerrado" — solo los usuarios autenticados tienen acceso.

Estructura de las Reglas

Las reglas de Realtime Database se escriben en formato JSON con las secciones .read, .write, .validate, .indexOn. A diferencia de Firestore (que utiliza sintaxis match), Realtime Database utiliza objetos anidados que reflejan la estructura de datos. Las condiciones verifican auth (autenticación), data (datos existentes), newData (nuevos datos al escribir) y now (hora del servidor). Las reglas de validación (.validate) permiten verificar tipos, rangos de valores y estructura de datos.

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth.uid === $uid",
        ".write": "auth.uid === $uid",
        ".validate": "newData.hasChildren(['name', 'email'])"
      }
    },
    "messages": {
      ".indexOn": ["timestamp"],
      "$msgId": {
        ".read": true,
        ".write": "auth.uid !== null",
        ".validate": "newData.child('text').isString() && newData.child('text').val().length <= 500"
      }
    }
  }
}

Comportamiento en Cascada y Prueba de Reglas

Las reglas de Realtime Database se heredan en cascada — si .read = false en el nivel superior, entonces todos los nodos hijos no están disponibles para lectura independientemente de sus propias reglas. Firebase proporciona un simulador de reglas en la consola donde se pueden probar operaciones con diferentes tokens de autenticación antes del despliegue. Se recomienda probar siempre las reglas en el simulador — un error en una regla puede abrir el acceso a datos privados de todos los usuarios. Según Google (2026), el 40% de las filtraciones de datos en proyectos Firebase son causadas por reglas de seguridad mal configuradas.