What does it mean that Quickbase is single threaded ?

QuickBase is single threaded within an eco system of Apps which are connected.  Apps are considered connected if they have cross app relationships or I believe Report Link fields also cause them to be connected.

If you have large data sets  and / or large numbers of users on the same app, then planning is required to avoid casually causing apps to be connected.  Using Sync tables is the main tool we have as an alternative to cross app relationships.

It's hard to say what "large" is since it really does depending on the complexity of the relationships and the use of summary fields.

It's not that all cross app relationships are automatically bad, it's just that it will cause those two apps to be treated as one large app for the "single thread processing".

If you just have 1 app which is not connected to others then the single threading is for that app.

Your actual app will live on a server used by other apps from other users unrelated to your company.  They can also affect your perceived performance.

Thank you for your quick reply on this. I did have some additional follow up questions though:

1. Does single threaded mean that only one request can be processed at any given point in time ? i.e if one user is loading a report while another is submitting a form, are they sequenced one behind the other ? 

2. What are the common pitfalls in which this single threaded nature causes performance concerns ? 

3. Can someone confirm for sure if the report link too causes apps to be connected ? It feels like that should not be the case. 

1. Does single threaded mean that only one request can be processed at any given point in time ? i.e if one user is loading a report while another is submitting a form, are they sequenced one behind the other ?  YES - if it's some kind of killer report that takes 10 seconds to calculate, then for those 10 seconds, other users are frozen.  Of course I'm talking about the time to process the report.  Once the data is calculated to be sent, it does not matter if the user is on an ancient dial up modem with no speed - that time is not counted.

2. What are the common pitfalls in which this single threaded nature causes performance concerns ? The main pitfall is less with a single app, I mean you generally gotta do what you gotta do to get the app working.  But the main pitfall (and this was the case for my main client who has 10 years of app development - mostly by me and before we had Sync tables) and a spider web of connected applications is that they now load as one giant single threaded eco-system.  So there are probably 20 large apps all interconnected and 250 users.  Actually the performance is pretty good - EXCEPT that it is mission critical to update the main app with updating 30,000 Open Order lines and say 15,000 Orders every few hours.  That is done with QuNect every 2-3 hours in the day and the eco-system slows down during those reloads.  We use some kind of feature called chunking with those updates so that the update process does not hog all the QuickBase cycles.  It does a batch of a few thousand or hundreds of records, takes a pause and then starts again,  so that way other users can get requests queued up and they maybe wait 10-15 seconds but at least they are moving.

3. Can someone confirm for sure if the report link too causes apps to be connected ? It feels like that should not be the case. That is my understanding from Support when I as trying to unhook app from the eco-system. They have diagnostic tools to tell if an app is connected to other apps.  You an put in a support ticket and update this post here when you get an answer.

Performance is inversely related to # of concurrent users times # of records times complexity of summary fields being used on reports and records.  The "times factor" is not scientifically knowable, it is mainly through experience.   

If you have tables with a few thousand records, there will not be any problems.  If you have tables with 200,000+ records involved with summary fields a records, then you have to be very careful about Performance pitfalls.

Thanks Mark! 
Would you consider sync tables a better option than cross app relationships ? 

... let me think for a moment.

YES YES YES YES YES YES YES YES :)

Once you get the knack of these sync tables they are super quick to setup.  Be sure to use a robot type system userid as the Sync will die when you do - or when you lose access to the app, so I suggest that you have a generic userid for the Sync.

It is also often a better user experience anyways to say bring in a nice table of Customers instead of just that cross app lookup. Often  a user may want to look at a customer record and see an embedded child table of their detail records being processed by the app.

Sync tables are "best practice". They did not exist a couple of years ago, but now that they exists, yes that is what you want to do.  They are Quick Base's main answer to avoiding eco-systems of connected and hence performance challenged apps.  Also, when a Sync table is updating, say every hour, they seem to have them tuned to not impact performance at all.  The must run as low priority "end of the queue" in the single threaded queue vs real users working with an app to run reports or process records.

But that'll really be valuable and usable for lookup type records. right ? i.e if i have a bunch of inter-related tables that need to taken and used, then we'd have to setup sync for each table and then set their relationships all over again. right ? Wouldn't that cause possible sync mismatch issues ?

Suppose that you have a Primary customer table fed with a bunch of lookup for 
Customer Type
Customer Branch (with lookups for Sales manager name, address,  email)
Customer Sales Rep (as well as lookups like rep userid and rep email and rep address)

Keep in mind that when you do the Sync table all those lookups come down as just plain old text fields. ie not lookups.  So you don't have to re-look them all up, they all just come in from the Customer record.  The only trick is that user fields come down as text so you suffix the name with (text) and then make a formula 
for say Sales Rep userid 
 to be
ToUser(Sales Rep userid(text)]) 

So no, you do not need to go through the effort to re-look up the info, as it comes down pre-baked are ready to eat.

great! and when those lookup values change for whatever reason, they get pushed back to the application where the sync table is being pulled into ? 

Yes indeed!

awesome! Thanks again Mark!