Forum Discussion

4 Replies

  • Hi Ryan,

    The applications themselves do not have a strictly imposed technical limit on their size. Instead what is more regulated is the size of a specific table, tables are restricted to 500 MB for performance purposes and as a table approaches that size there can be some technical issues. One thing to note for an application is that after 75 MB an application may no longer be able to be copied by the Admin and instead a Care case may be needed to have our Care team create a copy on our end. Also, the larger an application gets the more performance concerns and implications that application can have. More data, fields, and records can cause longer queue waits while tables/applications are loaded or searches are performed. I hope this information is helpful Ryan. 
    • MCFNeil's avatar
      MCFNeil
      Qrew Captain
      Those sizes do not include file attachments.

      And as a reference... its about 1 MB / field with 100,000 records

      Thats to say a table of 50 fields, and 100,000 records, would be 'about' 50 MB. 
      (this varies based on the complexity of the fields, summaries & values within the fields.)

      Also a blank field still takes up space,  the system still has to store a 'null' value.  So if you have fields that aren't getting used, you can free up a lot of space on the big tables by deleting the old fields.
  • Thanks, one of the apps that I am running has hit 1.3GB and I was starting to wonder if the QB 5-0 were going to write me a ticket. Seems unlikely now.
  • Hi Orion,

    We most often reach out to users when a performance issues becomes significant enough to be caught by our Operations team. These performance issues are more likely in large applications or in environments where multiple applications are interdependent and so have to all stay in the same server together in order to function. While a larger application or dependent application is more likely to raise those performance flags there are larger applications that run without issue. We do often recommend builders consider the possibility of archiving records from tables that are no longer needed on a regular day to day basis or aren't specifically being used for active reporting. I often do this by making a copy of the application without data and then using a table to table import in Quick Base to move those older records out of the main app and into my mirrored archive app. This helps to free up some space in a table that has grown large and to help speed up the application performance when it comes to reporting, searching, and navigation. They aren't hard and fast rules but they are suggested best practices to make sure you and your users are getting the most out of your applications.