Suggestions for archiving or closing records

Archiving and summarizing can be a lot of development work for active buildings which have a long history.

One thought is that an asset which is no longer active is much more easy to archive off than an active asset.

Can I ask for the ballpark record counts in some of your larger tables, and what percent full those tables are?

I'm asking that because if you still have many years left before you are forced to archive due to the 500 MB table limits, then maybe some initial efforts instead should be to find ways to optimize the runtime for reports that are run frequently.

Do you have the filters on these reports set in the proper sequence so that you filter out the most records possible with the initial filters? Do you have columns on the report which are not really necessary, especially columns involving summary fields?

have do you have Table home pages which are needlessly causing the system to sort up hundreds of thousands of records every time I user goes there.

Another thought I have is too copy the app assuming it's all one big app, and arbitrarily dropping off and deleting half the data to satisfy yourself that if you did all that archiving work,  that the app actually would run much faster. You wouldn't want to go through a whole lot of development archiving work only to find out a screen loads maybe 25% faster which is saving your user maybe 1 second  on some reports 

Another thought is that some of the process processing gets done locally on your computer. Sometimes what I have done is gone into an Apple Store or some kind of Microsoft store and try your application speed on the latest and greatest M3 Chip. Again, that would help you understand what part of the bottleneck is the local browser on your computer and rendering the data that is fed down the line.

Another test is whether or not the app feels slow only during the most heavily used time of the day, for example at 11 AM or 1:30 PM versus how it runs at 8:30 PM at night. That's also a clue.  

So I think you get where I am coming from, until you are forced into archiving due to QuickBase table size limits, I would first try to optimize dashboards and reports so that you are not needlessly wasting the single threaded server, which is allocated to your application.

I don't have links handy right now, but there are definitely blogs that have been written over the years about how to optimize performance, and QuickBase Support can probably point you at resources of things to review.