@fda2 Good that you found a working approach.    You are loading into a CAS session scope table. Report consumers are only impacted during the time when you drop the global scope table and promote the session scope table to global scope. This process should be rather quick and you can't improve it further.   I believe though there are some opportunities to improve on end-to-end performance and robustness.    Current state end-to-end performance You can load a CAS table client side (push from SAS compute) or server-side (pull from CAS).  Client-side loads serial  Pro SQL create table <caslib>.<table> is client-side loading robustness If CAS goes down then all in-memory tables will get wiped out You have to re-run the load process to re-create the CAS table Improvement ideas end-to-end performance Use Proc FedSQL for server side loading that runs in parallel (likely multi-node) You can use your existing SQL code for this if your join conditions don't contains expressions that SAS can't push to the database (else use explicit SQL) Using FedSQL to Pre-process Database Tables In-Database before Loading to CAS Load directly into caslib public The loaded table will be session scope. Under a caslib there can only be one global scope table with a specific name but you can per session also have a same named session scope table. These are separate objects and your session scope table won't impact any report consumers that use the same named global scope table. Drop the global scope table (use proc casutils or proc cas with a table action and not proc datasets). Promote the session scope table to global scope (this makes the table again available to your report consumers) Robustness Save the global scope CAS table back to it's physical permanent location As part of load process right after promotion to global scope  Permanent location as defined in the caslib definition for public (Proc casutils save or proc Cas table action) To allow for reload of data after a server restart without the need to re-run your load process After a CAS outage reload data directly from the permanent location into CAS No need to re-run the load process with the SQL query I would go for just-in-time loading Strategies for Reloading CAS Tables Just-in-time loading won't impact time for server start-up but still ensures data is available to report consumers already before your next scheduled load process runs. Server restarts during business hours should be rare so time penalty for the first report consumer after restart likely acceptable. You're using caslib Public which likely stores the permanent data as memory mapped sashdat files. If volumes aren't massive then load time likely acceptable. Further considerations for report performance and CAS memory consumption If you know that the reports often create aggregations by one or multiple classification variables then use the partition option to load data that belongs to the same values of classification variables onto the same CAS worker node. This will reduce data movements between CAS workers and though improve query performance. Example: Let's say you've got financial transaction data that includes a customer and account column. Each account has only one primary account holder. In such a case you could partition by customer as this will keep all transactions belonging to the same customer on the same CAS worker node.  Consider how many replications you need (how many time to replicate data with copies on multiple nodes) Consider the CAS data types - especially Varchar vs Char. Only use Varchar if the length is >16 characters and if the strings are really varying. If you have fixed length strings always use Char (Varchar consumes extra memory for storing the varying length information).     ... View more