Is there a way to handle situations where a user has blocked more than 10 users, so that the app doesn’t exceed Firestore’s not-in query limit?

Question

func fetchNextPage() async {
    guard !isLoading, !reachedEnd else { return }
    isLoading = true
    defer { isLoading = false }
    
    let excluded = Array(BlockService.shared.blocked.prefix(10))
    
    var query = db.collection("posts")
        .whereField("isReply", isEqualTo: false)
        .order(by: "timestamp", descending: true)
    
    if !excluded.isEmpty {
        query = query.whereField("ownerUid", notIn: excluded)
    }
    
    if let lastDoc { query = query.start(afterDocument: lastDoc) }
    query = query.limit(to: pageSize)
    
    do {
        let snap = try await query.getDocuments()
        
        guard !snap.documents.isEmpty else {
            reachedEnd = true
            return
        }
        
        let items = snap.documents.compactMap { try? $0.data(as: Post.self) }
        let posts = await PostService.hydratePosts(items)
        
        self.posts.append(contentsOf: posts)
        lastDoc = snap.documents.last
        if snap.documents.count < pageSize { reachedEnd = true }
    } catch {
        Crashlytics.crashlytics().record(error: error)
        
        #if DEBUG
            print("DEBUG: Unable to fetch posts with error: \(error.localizedDescription)")
        #endif
    }
}

Currently, Firestore’s not-in operator is limited to 10 values, which restricts users from blocking more than 10 others. Is there an efficient way to work around this limitation and support unlimited blocked users? I don't want to filter client side. I want to keep everything a query so I can implement Firestore rules.

Firestore's not-in operation is limited to 30 values nowadays (not 10): firebase.google.com/docs/firestore/query-data/…. If this code still somehow tells you the limit is 10, that's coming from the SDK and should be fixed there. — Frank van Puffelen
– Frank van Puffelen, Commented Oct 25 at 16:20

Frank van Puffelen · Accepted Answer · 2025-10-25 16:28:13Z

The only alternative is to store the feed for the current user in the database, rather than querying it live. That way you can exclude the posts from blocked users when you're writing the data, rather than doing it at read-time.

This is one of the most common trade-offs you have to do when using a NoSQL database such as Firestore, where the query capabilities are often more limited than for a relational database. If you have a use-case that can't be met with the query capabilities, you'll have to modify your data model to allow the use-case.

Duplicating data such as I describe above (often also called fanning out data) is a common approach. While it makes the write operation more complex, the assumption when using a NoSQL database is that write operations are much less frequent than reads - so a more complicated write and storing duplicated data balances out over the multitude of reads.

If this strikes you as "unnatural" or "wrong", consider using a relational database instead. There is nothing wrong with that - as long as you also keep in mind that most social networks use a mix of the above and relational techniques.

Collectives™ on Stack Overflow

Is there a way to handle situations where a user has blocked more than 10 users, so that the app doesn’t exceed Firestore’s not-in query limit?

1 Answer 1

Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

Comments

Your Answer

Sign up or log in

Post as a guest

Related