How to Debug FlutterFlow Database Queries (Firestore & Supabase)

Open the page or widget that has the failing Backend Query. Click the Backend Query icon (the database cylinder icon) on the widget or page to open the query editor. Go through each field systematically: 1. Collection path: Firestore paths are case-sensitive. 'Users' and 'users' are different collections. If your Firestore collection is named 'orders', the path in FlutterFlow must be exactly 'orders' — not 'Orders' or 'order'. For subcollections, the path must alternate document and collection: 'users/{userId}/orders'. 2. Filter field names: Every field name in your filter conditions must exactly match the field name in Firestore or Supabase — including capitalization. Open Firebase Console → Firestore → your collection → any document and read the field names directly. Compare them character-by-character to what you typed in FlutterFlow. 3. Filter operators: Confirm you are using the correct operator for the data type. Using 'Equal To' on a Timestamp field when the stored value includes milliseconds will never match. Use 'Less Than or Equal To' with end-of-day timestamp for date range queries. 4. Order By field: If you have an Order By set, confirm the field exists on every document in the collection. A single document missing that field can cause the entire query to return nothing in some configurations.

The fastest way to determine whether your query logic is correct is to run it directly in the Firebase Console, bypassing FlutterFlow entirely. Open Firebase Console → Firestore Database → Data tab → navigate to your collection. Click the Filter icon in the top-right of the collection view. Add the same filter conditions you have in your FlutterFlow Backend Query — same field, same operator, same value. Click Apply. If the Firebase Console filter returns documents, the query logic is correct and the problem is in FlutterFlow's configuration or auth context. If the Firebase Console filter also returns zero results, the problem is in your data or query logic itself — not FlutterFlow. For inequality filters combined with orderBy: Firestore requires that when you use a filter like 'status != completed' or 'price > 100', the first orderBy field must match the inequality filter field. If you orderBy 'createdAt' but filter on 'price > 100', Firestore rejects the query. In Firebase Console you will see the error message that FlutterFlow hides.

When a Firestore query combines a filter on one field with an orderBy on a different field, Firestore requires a composite index — it cannot run this query without one. FlutterFlow does not surface the resulting error to the UI; the query simply returns nothing. To find missing index errors: open Firebase Console → Firestore Database → Indexes tab. Look for any indexes with a 'Building' or 'Error' status. Alternatively, open Firebase Console → Firestore Database → Usage → Log entries and look for error messages containing 'FAILED_PRECONDITION' or 'The query requires an index'. The error message in the logs will include a direct URL to create the exact index you need — copy that URL into your browser and click 'Create Index'. Index creation takes 2-10 minutes depending on collection size. Three query patterns that always require composite indexes in Firestore: - Filter on field A + orderBy on field B (different fields) - Filter with inequality (!=, <, >, <=, >=) + any orderBy - Two or more inequality filters on different fields (not supported at all — requires restructuring) For arrayContains queries: the arrayContains operator only works on fields that actually store an array type. If the field stores a string or number, arrayContains always returns zero results without an error.

For Supabase backends, open your Supabase Dashboard → SQL Editor. Write a direct SELECT query matching your FlutterFlow query: SELECT * FROM your_table WHERE your_filter_column = 'your_value' ORDER BY created_at DESC LIMIT 20; If this query returns rows in the SQL Editor, the data exists and the logic is correct. The SQL Editor runs as the Postgres service role, which bypasses Row Level Security. To test what a real authenticated user would see, run: SET LOCAL ROLE authenticated; SET LOCAL request.jwt.claims = '{"sub": "YOUR_USER_UUID"}'; SELECT * FROM your_table WHERE your_filter_column = 'your_value'; If this returns fewer rows or zero rows, an RLS policy is blocking the read. Go to Authentication → Policies and review the SELECT policy on your table. Common RLS mistakes that cause silent query failures: 1. RLS is enabled but no SELECT policy exists — all reads are blocked for authenticated users 2. The SELECT policy uses auth.uid() = user_id but the user_id column stores the email instead of the UUID 3. The policy has a typo in the column name — Supabase silently treats it as a null comparison 4. Multiple conflicting policies — one permissive policy and one restrictive policy interact unexpectedly In FlutterFlow's Supabase Backend Query editor, confirm the Filter Row field names exactly match the Supabase column names (case-sensitive).

1-- Test query as service role (bypasses RLS) — paste in Supabase SQL Editor
2SELECT * FROM orders
3WHERE status = 'active'
4ORDER BY created_at DESC
5LIMIT 20;
6
7-- Test the same query as an authenticated user
8-- Replace YOUR_USER_UUID with an actual user's UUID from auth.users table
9SET LOCAL ROLE authenticated;
10SET LOCAL "request.jwt.claims" = '{"sub": "YOUR_USER_UUID", "role": "authenticated"}';
11
12SELECT * FROM orders
13WHERE status = 'active'
14ORDER BY created_at DESC
15LIMIT 20;
16
17-- Check which RLS policies exist on the table
18SELECT schemaname, tablename, policyname, permissive, roles, cmd, qual
19FROM pg_policies
20WHERE tablename = 'orders';
21
22-- Check if RLS is enabled on the table
23SELECT relname, relrowsecurity
24FROM pg_class
25WHERE relname = 'orders';

FlutterFlow's Test Mode (the browser preview) runs in a different environment than the deployed app — it may use a different auth token, different security context, or bypass certain Firebase Security Rules checks. Never conclude a query is working based solely on Test Mode results. To test with real auth context: 1. In FlutterFlow, click the Run button (triangle icon, top-right) instead of the Test button 2. Select your target platform (iOS or Android) 3. FlutterFlow will build and push to your connected physical device or emulator 4. Log in with a real test user account — not the FlutterFlow preview account 5. Navigate to the page with the failing query and observe whether data appears For additional visibility, add a temporary debug display to your page: - Add a Text widget outside the query-bound widget tree - Bind it to a Page State variable named debugInfo (String) - In the Backend Query's On Completed action: Update Page State → debugInfo → set to 'Query complete. Count: ' + query_result_count - In the On Error action: Update Page State → debugInfo → 'Error: ' + error_message This makes invisible failures visible. Remove these debug widgets before publishing.

Apply the fix for whichever issue you identified in the previous steps: For collection path or field name errors: correct the typo in the Backend Query editor. Remember to check every filter condition — if you have three filters, all three field names must be verified. For missing Firestore indexes: wait for the index to finish building (Firebase Console → Indexes → status turns green). Then re-run your query. Indexes that are still building return zero results without an error. For RLS policy issues in Supabase: update or create the SELECT policy in Authentication → Policies. The simplest correct policy for user-owned data is: (auth.uid() = user_id) where user_id is the UUID column linking rows to the authenticated user. For inequality + orderBy conflicts: restructure the query to add orderBy on the filter field first, then add secondary orderBy fields. After applying the fix: 1. Test in Firebase Console or Supabase SQL Editor — confirm data returns 2. Run on physical device with your test account — confirm the UI populates 3. Test with a second user account that should NOT see the data — confirm it is empty for them 4. Remove all debug Text widgets and Page State debug variables before publishing