How to Scale Your FlutterFlow Database for High Traffic

When FlutterFlow creates a new Firestore document via Add Document in an action flow, it uses auto-generated document IDs by default. This is intentional — Firestore distributes documents with random IDs across multiple storage shards. If you override this and use sequential IDs (1, 2, 3, or timestamps as strings), Firestore stores adjacent documents on the same storage shard, creating a write hotspot. At high write volume (100+ writes/sec), sequential IDs cause 429 Too Many Requests errors. In FlutterFlow's Action Flow Editor, when adding a Create Document action, leave the Document ID field empty to use auto-generated IDs. If you need sequential numbering for display, store a separate displayId field as an Integer that you auto-increment, but keep the document ID as Firestore auto-generated.

A Firestore document has a hard 1MB size limit. If you store messages, comments, orders, or activity logs as arrays or maps inside a parent document, that document will hit 1MB as data grows and subsequent writes will fail with Document size limit exceeded. The solution is subcollections. In FlutterFlow's Firestore panel, instead of adding a messages array field to your conversations document, create a messages subcollection under conversations/{conversationId}. Each message is then an independent document in conversations/{conversationId}/messages with its own ID, timestamps, and fields. The parent conversation document stays small and fast. When querying, use a Backend Query on the subcollection path conversations/{conversationId}/messages with ordering and limit. This pattern applies to: chat messages under conversations, order items under orders, comments under posts, and activity events under users.

A single Firestore document supports approximately 1 write per second sustained. If you have a popular post that many users like simultaneously, storing the like count as a single integer field on the post document creates a write bottleneck. The distributed counter pattern splits the counter across N shard documents and sums them on read. Create a Cloud Function named incrementCounter that accepts collectionPath and documentId. The function randomly picks a shard (0 to N-1), then does a batched write: increment the shard document's count field using FieldValue.increment(1). For reading the total, create a second Cloud Function sumCounter that queries all shards and returns the sum. In FlutterFlow, when a user likes a post, call the incrementCounter function via API Call action. To display the count, call sumCounter or cache the sum in the parent document via a scheduled Cloud Function that runs every minute.

1// Cloud Function: incrementCounter (distributed counter)
2const admin = require('firebase-admin');
3
4exports.incrementCounter = async (req, res) => {
5  const { collectionPath, docId, numShards = 10 } = req.body;
6
7  // Pick a random shard
8  const shardId = Math.floor(Math.random() * numShards);
9  const shardRef = admin.firestore()
10    .doc(`${collectionPath}/${docId}/shards/${shardId}`);
11
12  await shardRef.set(
13    { count: admin.firestore.FieldValue.increment(1) },
14    { merge: true }
15  );
16
17  res.json({ success: true, shard: shardId });
18};
19
20exports.sumCounter = async (req, res) => {
21  const { collectionPath, docId } = req.body;
22
23  const shards = await admin.firestore()
24    .collection(`${collectionPath}/${docId}/shards`)
25    .get();
26
27  const total = shards.docs.reduce(
28    (sum, doc) => sum + (doc.data().count || 0), 0
29  );
30
31  res.json({ total });
32};

FlutterFlow's Backend Query has a built-in limit field. Set this to 20-50 documents to avoid loading thousands of records on page load. For infinite scroll (load more as user scrolls), you need cursor-based pagination using the last document as the starting point for the next page. In FlutterFlow, add a Page State variable named lastDocumentSnapshot of type DocumentSnapshot. On the Backend Query's initial load, set limit to 20. Add a Load More button at the bottom of your ListView. In the button's action flow: call the same Backend Query with an additional startAfterDocument parameter bound to lastDocumentSnapshot Page State. Append the new results to your existing list (App State or Page State list). Update lastDocumentSnapshot to the last item in the new results. Add a hasMore Boolean Page State variable that becomes false when the returned results count is less than the page size.

When your Backend Query filters by one field AND orders by another field (e.g., filter by category == 'electronics' AND orderBy price ASC), Firestore requires a composite index. Without it, the query returns a permission-denied or failed-precondition error, and the data never loads in your app. Firestore tells you exactly which index to create: in FlutterFlow's Run Mode or in the Firebase Console, open the Firestore error logs and look for a URL in the error message. Clicking this URL auto-fills the index configuration in Firebase Console — click Create. Alternatively, go to Firebase Console → Firestore Database → Indexes → Composite → Add Index → specify the collection, fields, and sort orders. Indexes take 2-10 minutes to build. Your query works correctly once the index status shows Enabled.