Skip to main content
Question

Apps, Performance, and Best Practice

  • October 6, 2020
  • 0 replies
  • 258 views
Forum|alt.badge.img+14

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
------------------------------

  • AustinK
  • Quickbase Alumni
  • October 6, 2020
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.
MarkShnierYou
Forum|alt.badge.img+22
  • MarkShnierYou
  • Quickbase Alumni
  • October 6, 2020
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
------------------------------
Mark Shnier. Your Quickbase Coach
  • BlakeHarrison
  • Quickbase Alumni
  • October 6, 2020
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
------------------------------
Forum|alt.badge.img+17
  • EvanMartinez
  • Community Moderator
  • October 7, 2020
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
------------------------------
Terms & ConditionsAccessibility statement