Relationship mastery (hidden performance killer)

Quickbase actually does a great job of performing even in a complex app with hundred of tables and many summary and lookup fields.  As long as you actually don't have circular relationships, it will all work.  If you have reports which rely on complex summary fields, the report might take a second or two longer to load. 

Can you give us some idea of the record counts in these tables? If yoou are dealing with under 250,000 "ish" records per table, then there is usually no performance issues.  Once you get into like a million records, then you may start to see performance issues or actually hit table size limits of 500 MB if you have many many scalar (data entry) fields.

I was typing the same thing as Mark but he beat me to it. Quickbase is very performant. I was running API requests on 1M records that were completing in not even 1 second. This is to say a performance issue might be local to your device or application structure, rather than the platform.

From an architecture perspective, what warning signs tell you an app is becoming too relationship-heavy before actual performance issues appear? For example, are there common indicators like excessive lookup chains, too many summary dependencies, report delays, or difficulty troubleshooting formulas?

I’m also interested in best practices for designing large-scale Quickbase apps that may eventually cross the 250K–1M+ record range. At what point do you typically start introducing patterns like archive tables, stored fields, or pipelines instead of relying purely on native relationships?