Partitioned tables are mainly used to improve performance and reduce billing costs. Most reporting application queries include filters by date range, and in that case, partition tables will be highly helpful. Partition tables are not just for raw data tables or historical tables; they should also be used in aggregate tables and staging tables. 

The daily data loading jobs should load data into specified partitions, and in case of any cleanup or reloading, that individual partition can be deleted without affecting other partitions and reloading the data. This can be done concurrently for multiple partitions. Tables that are used as staging tables to load data temporarily and delete it after some period can use the expiration option to delete partitions after a specified number of days.

The application that executes the query should also make use of the _PARTITIONTIME column to query data, and only from a limited set of partitions instead of the entire table. If there is any other date column in the table that the app uses to query, then there is no use having a table as a partition table because the entire table may be queried to retrieve just a few days of data.

The following are the current limitations of a partition table:

• A partition table can have only up to 2,500 partitions
• Only 2,000 partitions can be updated in a day
• Only 50 partitions can be updated every 10 seconds