Firebase Firestore: what it is, NoSQL and how it works

What is Firebase Firestore?

Firebase Firestore is a flexible, scalable NoSQL database launched by Google in 2019 as an evolution of the Firebase Realtime Database. It stores data in collections of documents, where each document contains a set of key-value pairs. Unlike traditional relational databases, Firestore does not require a predefined schema — the data structure is formed dynamically based on the documents being written.

The key difference between Firestore and classic cloud databases is built-in real-time synchronization. When data changes on the server, all connected clients receive updates through a persistent WebSocket connection. This eliminates the need for manual server polling and allows building applications with live updates: chats, activity feeds, collaborative editors, and monitoring systems.

The database is available on all major platforms: Android, iOS, Web (JavaScript) and server-side languages via Admin SDK. Firestore provides SDK for Swift, Kotlin, JavaScript, Python, Go, Java and Node.js. According to Google, Firestore processes over 100 billion requests per day across the entire Firebase ecosystem, confirming its reliability as a foundation for production applications.

Core concepts: collections and documents

In Firestore, data is organized in a hierarchical structure. A collection is a container for documents, similar to a table in SQL but without a fixed schema. A document is a record containing fields of various types: strings, numbers, booleans, arrays, nested objects, and geopoints. Documents can contain subcollections, allowing you to build nested data structures of any depth.

val db = FirebaseFirestore.getInstance()

val user = hashMapOf(
    "name" to "Anna Petrova",
    "email" to "anna@example.com",
    "age" to 28,
    "isActive" to true
)

db.collection("users")
    .add(user)
    .addOnSuccessListener { docRef ->
        Log.d("TAG", "Document added with ID: ${docRef.id}")
    }

Each document in a collection has a unique identifier, which can be auto-generated or set manually. Firestore automatically indexes all document fields, enabling complex queries with filtering, sorting, and result limiting without manual index configuration.

Firebase Firestore vs Realtime Database: comparison

Firestore and Firebase Realtime Database are two cloud real-time databases from Google. While both provide real-time synchronization, they have fundamental differences in data model, scaling, and pricing. Understanding these differences is critical when choosing the right database for a specific project.

The main architectural difference is the data model. Realtime Database stores everything in one large JSON tree, which complicates queries with deep nesting. Firestore uses collections and documents, enabling complex queries with multiple conditions. Additionally, Firestore provides strong data consistency: after a successful write, all subsequent reads are guaranteed to return the latest data.

Scalability and data structure

Firestore scales automatically to millions of concurrent connections thanks to its multi-region architecture. Realtime Database is limited to a single region and a maximum of 200,000 concurrent connections. For projects targeting a global audience, Firestore is preferable, as data is automatically replicated across multiple Google data centers.

The data structure in Firestore allows building complex hierarchical models with subcollections. For example, a user can have an "orders" subcollection, and each order can have an "items" subcollection. In Realtime Database, such deep nesting leads to performance issues during queries, as the entire path from root to the needed node is loaded.

How data synchronization works in Firestore

Firestore uses a persistent WebSocket connection between the client and server for real-time data synchronization. When an application subscribes to changes in a document or collection via a snapshot listener, the SDK establishes a communication channel through which the server sends updates whenever data changes. The client receives only changed documents, not a full snapshot of the entire collection each time.

The synchronization mechanism is based on an event stream: added (document appeared), modified (document changed), and removed (document deleted). The developer can handle each event separately, updating only the corresponding UI elements. This ensures high performance even with thousands of documents, as only changed components are re-rendered.

Offline access and caching

One of the key advantages of Firestore is built-in offline mode support. The SDK automatically caches all read data on the device and continues working when there is no network. When the application writes data in offline mode, it is placed in a local queue and sent to the server when the connection is restored. The last-write-wins strategy is used for conflict resolution.

val docRef = db.collection("cities").document("SF")

docRef.addSnapshotListener { snapshot, error ->
    if (error != null) {
        Log.w("TAG", "Listening error", error)
        return@addSnapshotListener
    }

    if (snapshot != null && snapshot.exists()) {
        Log.d("TAG", "Current data: ${snapshot.data}")
    }
}

The cache size can be configured via FirestoreSettings. The default value is 100 MB, but it can be increased for applications with intensive data reading. A persistent disk cache mode is also available, which survives application restarts. To manage offline mode availability, the enableNetwork and disableNetwork methods are used, allowing temporary network interaction disabling.

Firestore security and access rules

Firestore Security Rules is a declarative markup language for controlling data access at the server level. The rules define who can read and write documents and under what conditions. They work before query execution and do not require separate server logic for authorization. Rules are checked on the Firebase side before each data read or write.

Access rules are built on the allow principle. By default, all access is denied. The developer sequentially opens access for specific operations (read, write, create, update, delete) under certain conditions. Conditions can check user authentication via request.auth, request data via request.resource, and existing data via resource.

// Firestore access rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // User reads and writes only their own data
    match /users/{userId} {
      allow read, write: if
          request.auth != null &&
          request.auth.uid == userId;
    }

    // Any authenticated user can read posts
    match /posts/{postId} {
      allow read: if request.auth != null;
      allow create: if request.auth != null
          && request.resource.data.author == request.auth.uid;
    }
  }
}

Data validation through rules

In addition to access control, Security Rules allow validating the structure and types of written data. For example, you can check that the email field matches a regular expression, or that the age does not exceed 120 years. Validation is performed before writing, preventing incorrect data from being saved on the server. The request.resource.data object containing the entire document being written is used for field validation.

Firestore also supports collections that are only accessible for server-side writing via Admin SDK, without client access. This is convenient for storing service information, API keys, and configurations that should not be visible to users. For this purpose, it is enough to deny all client operations on the corresponding collections in the rules, allowing access only through Admin SDK from the server side.

Example of using Firebase Firestore in Android

Let's look at an example of integrating Firestore into an Android application for creating a todo list. The application will read tasks in real-time, add new ones, and mark completed ones. Firebase callback interfaces and Kotlin coroutines are used for asynchronous work.

Firebase setup and adding dependencies

Before starting, you need to connect the project to Firebase via Firebase Console and add the google-services.json file to the application module. Then add the firebase-firestore-ktx dependency and the google-services plugin in build.gradle. The library version must match the current Firebase BoM version for compatibility of all Firebase components with each other.

dependencies {
    // Firebase BoM — version management
    implementation platform("com.google.firebase:firebase-bom:33.0.0")
    implementation "com.google.firebase:firebase-firestore-ktx"
    implementation "org.jetbrains.kotlinx:kotlinx-coroutines-play-services:1.9.0"
}

After setup, a Task data model and a repository for working with Firestore are created. The model contains id, title, isCompleted, and timestamp fields. Firestore automatically serializes the data class into a document, using field names as keys. For reading data, a snapshot listener is used, which returns a Flow via the snapshotFlow extension.

data class Task(
    val id: String = "",
    val title: String = "",
    val isCompleted: Boolean = false,
    val createdAt: Timestamp? = null
)

class TaskRepository {
    private val tasksRef = FirebaseFirestore
        .getInstance()
        .collection("tasks")

    fun getTasks(): Flow<List<Task>> = tasksRef
        .orderBy("createdAt", Query.Direction.DESCENDING)
        .snapshotFlow()
        .map { snapshot ->
            snapshot?.toObjects(Task::class.java) ?: emptyList()
        }

    suspend fun addTask(title: String) {
        tasksRef.add(Task(title = title))
    }
}

The ViewModel subscribes to the Flow from the repository and passes the task list to the UI level. When a new task is added, the repository's suspend function is called via a coroutine scope. Firestore automatically synchronizes changes between all clients: if one user adds a task, others see it in real-time without refreshing the screen.