I prefer to have a very limited number of apps, as management can be come quite labor intensive, and I tend to find cross app relationships with some limitations or inconveniences versus staying within a specific app. Additionally, I find a single app better for my use cases, and less complicated for users.I in fact of three apps, but don't have an intention to expand to more apps. One is essentially a master app, that feeds into two separate project manager apps.My master app has 150+ tables and growing. I am wondering if anyone has had performance issues as apps grow in size, and if best practice for best performance is to continue inside one app, or call to other apps. I would prefer to keep growing as I am now, unless convinced I will regret it down the road. Thoughts?------------------------------Mike Tamoush------------------------------

Do you use the sandbox feature? If you do then keeping your app size to under 1 GB is a huge deal. My main app is above that limit so when using sandbox mode it can bring over exactly 0 records on any tables. You must do all the imports manually yourself if you want to see "live" data to play with. So annoying to do when you have a bunch of related tables that all need something populating. You might think why not create something to import via the API and I would say yes but you cannot do an API import with the sandbox enabled(API calls the read are supported, but not ones that write data...) I have reached out to support and even talked to an employee on these forums, it doesn't seem like it is a plan to increase this 1 GB limit. Personally I am at almost 2 GB in my main app so I have a long way to go to get back below 1.The other annoying part about importing like we have to to get around the sandbox issue is that not all tables still contain all of their original records, some have been deleted over the years. So when you go to import a set of data and that data is related via record id to something else, it is a nightmare getting them all set up correctly again. It can be done but it is just another annoying aspect of this.We are busy moving multiple related tables out into their own apps to slim down our main app, so moving in the opposite direction of you. This is because we started with one massive app and built off that and now feel like it is bloated. This is not always helpful because with some ways of connecting tables it brings both apps into the same instance and you really are not saving anything on performance. I forget exactly which option does this, but it was not hard for me to find previously. If you can separate the workflow enough sometimes a new app just makes sense and that is what we are exploring now.I will definitely be interested to hear others experiences with this. I don't know if we are moving down the right path either but it seems to make sense for us right now.

The Performance is related conceptually by # of concurrent active uses times # of records in the the tables being accessed frequently times the number of summary fields on reports. Those factors hurt performance.If you do go the route of separate apps, then you cannot make any cross app relationships or cross app saved table to table imports as that just makes it one giant app under the covers. So you need to use Sync tables to replicate master files like customers or warehouses.If you have many hundred of users like say 500+, then user count can be a factor, probably less than that, less of a concern. tables with hundred of thousands of records like say 200,000+ records can get to be a concern when combined with a high user counts using those big tables. They keep incrementally improving the performance of Quick Base each year, a bit like Elon's Battery day where there was no magic bullet to announce, but Tesla but is adding up the 5%'s and 10%'s they keep finding to improve the performance.So assuming no giant reports with killer summary fields and no frequently used tables approaching 500,000 records, you are probably going to be OK. 150 tables do not affect performance. It's the load on those tables in terms of concurrent users hammering away at difficult reports with complex summary fields.------------------------------Mark Shnier (YQC)Quick Base Solution ProviderYour Quick Base Coachhttp://QuickBaseCoach.commark.shnier@gmail.com------------------------------

Regarding your concern about application management, be careful. Applications that have large numbers of tables often become very difficult to manage as well, especially if you have multiple workflows intersecting across the application. In my experience, limiting the number of applications in order to make application management easier tends to come back to bite you in the end.I would encourage you to really think about what workflows are being handled by your application and decide if any of these can/should live on their own. As Mark pointed out, performance is really going to be impacted by your use of cross-app relationships, cross-app imports, table sizes, and the size of data sets on these tables. Ease of management is going to be impacted by # of Workflows in a single app, # of Tables, # of Fields on each Table, # of User Roles, # of Forms/Reports on each table, # of Dashboards, etc. You can split disparate workflows into separate applications and still have access to common tables like Customers, Resources, etc by using Sync tables. In that scenario, management may actually be easier because you've got less complexity within a smaller application, rather than running the entire business from one app and trying to figure out how to add/modify a process without causing issues with others.------------------------------Blake Harrison - DataBlender.ioQuick Base Solution Provider------------------------------

Austin - when speaking about app size for sandbox, does that include file attachments? If so, I'm dead in the water because we track assets (equipment) and have roughly 20,000 assets, each with about 5 pictures.....or 85 gigs worth of attachments. Without attachments, my apps are tiny. Blake - when you mention workflows, what exactly are you referring to? Automations etc?Mark - thanks for the tips. My largest table only ha maybe 20,000 records. I can see some tables growing but it will be many years I imagine until I even reach 100k in one table. I have a couple massive (I think? I have no frame of reference) tables of 500+ fields. So far so good, except my main table I ran out of Dynamic Form rules, so i will have to take some time to clean that up and rethink some of the fundamental design to alleviate that issue.I like to keep my user roles small, also for ease of management, but still need 6-8 roles. Which multiplied over three apps already starts to wear on the management. Sounds like this can really have a list of pro's and cons each way.------------------------------Mike Tamoush------------------------------

Mike, on the roles issues, note that you can have users in multiple roles. That can help so you don't need to feel that you need extra roles for users who cross some boundaries.------------------------------Mark Shnier (YQC)Quick Base Solution ProviderYour Quick Base Coachhttp://QuickBaseCoach.commark.shnier@gmail.com------------------------------

Apps, Performance, and Best Practice

22 Replies

AustinK
Qrew Commander
4 years ago
Do you use the sandbox feature? If you do then keeping your app size to under 1 GB is a huge deal. My main app is above that limit so when using sandbox mode it can bring over exactly 0 records on any tables. You must do all the imports manually yourself if you want to see "live" data to play with. So annoying to do when you have a bunch of related tables that all need something populating. You might think why not create something to import via the API and I would say yes but you cannot do an API import with the sandbox enabled(API calls the read are supported, but not ones that write data...) I have reached out to support and even talked to an employee on these forums, it doesn't seem like it is a plan to increase this 1 GB limit. Personally I am at almost 2 GB in my main app so I have a long way to go to get back below 1.

The other annoying part about importing like we have to to get around the sandbox issue is that not all tables still contain all of their original records, some have been deleted over the years. So when you go to import a set of data and that data is related via record id to something else, it is a nightmare getting them all set up correctly again. It can be done but it is just another annoying aspect of this.

We are busy moving multiple related tables out into their own apps to slim down our main app, so moving in the opposite direction of you. This is because we started with one massive app and built off that and now feel like it is bloated. This is not always helpful because with some ways of connecting tables it brings both apps into the same instance and you really are not saving anything on performance. I forget exactly which option does this, but it was not hard for me to find previously. If you can separate the workflow enough sometimes a new app just makes sense and that is what we are exploring now.

I will definitely be interested to hear others experiences with this. I don't know if we are moving down the right path either but it seems to make sense for us right now.
MarkShnier__You
Qrew Legend
4 years ago
The Performance is related conceptually by # of concurrent active uses times # of records in the the tables being accessed frequently times the number of summary fields on reports. Those factors hurt performance.

If you do go the route of separate apps, then you cannot make any cross app relationships or cross app saved table to table imports as that just makes it one giant app under the covers. So you need to use Sync tables to replicate master files like customers or warehouses.

If you have many hundred of users like say 500+, then user count can be a factor, probably less than that, less of a concern. tables with hundred of thousands of records like say 200,000+ records can get to be a concern when combined with a high user counts using those big tables.

They keep incrementally improving the performance of Quick Base each year, a bit like Elon's Battery day where there was no magic bullet to announce, but Tesla but is adding up the 5%'s and 10%'s they keep finding to improve the performance.

So assuming no giant reports with killer summary fields and no frequently used tables approaching 500,000 records, you are probably going to be OK. 150 tables do not affect performance. It's the load on those tables in terms of concurrent users hammering away at difficult reports with complex summary fields.

------------------------------
Mark Shnier (YQC)
Quick Base Solution Provider
Your Quick Base Coach
http://QuickBaseCoach.com
mark.shnier@gmail.com
------------------------------
- SystemAdmin4
  Qrew Member
  4 years ago
  Hi Mark,
  
  I'm really interested in (and potentially concerned by!) your comment:
  
  "If you do go the route of separate apps, then you cannot make any cross app relationships or cross app saved table to table imports as that just makes it one giant app under the covers. So you need to use Sync tables to replicate master files like customers or warehouses."
  
  Could you clarify please.
  
  My specific situation is I have a master database (used for content management, and not the fastest due to prolific use of summary fields) and a slave which I update overnight using API_RunImport.
  
  The slave is used to serve read only data to our customers within our web app via API calls).
  
  Are you saying that these two apps are run a single thread because of the use of the import API to refresh the slave tables, and therefore I won't actually be seeing any performance gain from separating the two?
  
  And if this is the case, are you are saying the only way to break this and ensure separate threads for the two apps is for the refresh of the slave tables to be using Connected tables / Quicbase Sync?
  
  Thanks
  
  David
  
  ------------------------------
  dmlaycock2000 dmlaycock2000
  ------------------------------
  - MarkShnier__You
    Qrew Legend
    4 years ago
    Yes, unfortunately when you have a saved table to table import it does create what is called an app dependencies between the two apps exactly the same as if there was a cross app relationship. So that means that these two apps will run in a single thread. It is still possible that your users will have a better user experience with two separate apps but in terms of performance it is identical to having one giant app.
    
    They are used to be a suffix parameter that you could use which I will list before but I don't know if it is working today I am just on my iPad and didn't test properly so far this morning. I was up late last night freebasing, oh I meant quickbasing, it's about the same level of addiction.
    
    ?a=ListDependentDatabases
    
    ------------------------------
    Mark Shnier (YQC)
    Quick Base Solution Provider
    Your Quick Base Coach
    http://QuickBaseCoach.com
    mark.shnier@gmail.com
    ------------------------------
BlakeHarrison
Qrew Captain
4 years ago
Regarding your concern about application management, be careful. Applications that have large numbers of tables often become very difficult to manage as well, especially if you have multiple workflows intersecting across the application. In my experience, limiting the number of applications in order to make application management easier tends to come back to bite you in the end.

I would encourage you to really think about what workflows are being handled by your application and decide if any of these can/should live on their own. As Mark pointed out, performance is really going to be impacted by your use of cross-app relationships, cross-app imports, table sizes, and the size of data sets on these tables. Ease of management is going to be impacted by # of Workflows in a single app, # of Tables, # of Fields on each Table, # of User Roles, # of Forms/Reports on each table, # of Dashboards, etc.

You can split disparate workflows into separate applications and still have access to common tables like Customers, Resources, etc by using Sync tables. In that scenario, management may actually be easier because you've got less complexity within a smaller application, rather than running the entire business from one app and trying to figure out how to add/modify a process without causing issues with others.

------------------------------
Blake Harrison - DataBlender.io
Quick Base Solution Provider
------------------------------
- MichaelTamoush
  Qrew Captain
  4 years ago
  Austin - when speaking about app size for sandbox, does that include file attachments? If so, I'm dead in the water because we track assets (equipment) and have roughly 20,000 assets, each with about 5 pictures.....or 85 gigs worth of attachments. Without attachments, my apps are tiny.
  
  Blake - when you mention workflows, what exactly are you referring to? Automations etc?
  
  Mark - thanks for the tips. My largest table only ha maybe 20,000 records. I can see some tables growing but it will be many years I imagine until I even reach 100k in one table.
  
  I have a couple massive (I think? I have no frame of reference) tables of 500+ fields. So far so good, except my main table I ran out of Dynamic Form rules, so i will have to take some time to clean that up and rethink some of the fundamental design to alleviate that issue.
  
  I like to keep my user roles small, also for ease of management, but still need 6-8 roles. Which multiplied over three apps already starts to wear on the management.
  
  Sounds like this can really have a list of pro's and cons each way.
  
  ------------------------------
  Mike Tamoush
  ------------------------------
  - MarkShnier__You
    Qrew Legend
    4 years ago
    Mike, on the roles issues, note that you can have users in multiple roles. That can help so you don't need to feel that you need extra roles for users who cross some boundaries.
    
    ------------------------------
    Mark Shnier (YQC)
    Quick Base Solution Provider
    Your Quick Base Coach
    http://QuickBaseCoach.com
    mark.shnier@gmail.com
    ------------------------------
EvanMartinez
Qrew Elite
4 years ago
Hi Mike,

I just wanted to chime in and share a few resources we have that touch base on Best Practices around sharing data across apps. It goes into the various options and what their pros and cons are, minus Pipelines which came out after this guide.

Sharing Data Across Quick Base Apps: Part 1 Cross App Relationships, Table to Table Imports, and Sync
Sharing Data Across Quick Base Apps: Part 2 Quick Base Actions, Webhooks, Automations, and 3rd Party Integrations.
Quick Base Memory Calculations
How we built Quick Base to scale and you can too!

As the other commenters have mentioned as an app gains in complexity and usage there is an increased chance of it needing more power and therefore having performance issues. Using methods like Sync, Automations, or Pipelines can help you avoid having apps directly connected but still be able to pass data back and forth and where possible it is a good best practice. In cases where I want to connect apps using these methods and still want to make it easy for users to move back and forth I have added buttons to the app dashboards that direct them to the right app/table to submit a form and buttons on the form to help them move back if needed. This way you can have a unified feeling experience but have ways to move data and users around. I hope those resources are helpful.

------------------------------
Evan Martinez
Community Marketing Manager
Quick Base
------------------------------
- SystemAdmin4
  Qrew Member
  4 years ago
  Hi Evan
  
  These resources are excellent - thanks for sharing.
  
  Could I ask you to clarify a point you make in the first document referencing the table to table imports, specifically:
  
  "TTIs create dependencies between applications when executed. Executing TTIs result in the share of system resources. "
  
  Is this basically saying that the depency and sharing of resources only occurs for the duration of the import (ie when it is actually executing the import)?
  
  So in my use case, I refresh my slave tables over night when there is almost no usage on either my master or slave app, so the shared resources and any performance issue on either app would not be an issue.
  
  Sorry if it seems like I'm basically asking the same question repeatedly, but I don't want to go rebuilding the way our apps work if I've simply misunderstood the nature of the dependency.
  
  Thanks
  
  David
  
  ------------------------------
  dmlaycock2000 dmlaycock2000
  ------------------------------
  - EvanMartinez
    Qrew Elite
    4 years ago
    Hi David,
    
    Not a problem at all it isn't always clear with TTIs how it all works, that is correct when a table to table import takes places the two apps that are involved get pulled together into one server in order to exchange that data. They will then stay there until the next time they would move around in the servers which isn't always on a fixed interval. If there is a saved table to table import they aren't able to separate from each other as the system respects that connection. One way around this that I have used which is a bit of a work around is to have a Scheduled Sync that syncs the data into a hidden sync table in the second app, then I use Automations or a Pipeline set to go off whenever records in the hidden Sync are added or modified and have it send all that new data over to my normal manual entry tables. This way I get the combo of a Sync table which doesn't cause the apps to be connected and the added bonus of all the data being put into my usual workflow where users can modify and act on it as needed.
    
    ------------------------------
    Evan Martinez
    Community Marketing Manager
    Quick Base
    ------------------------------