Sqlserver 2019 Partitioning based on Data Classification? Now that sqlserver 2019 has been around for a while, this is a re-ask of a prior question that was not really answered in the way I had hoped:

Is it possible to partition a database based on the Sqlserver 2019 data classification feature?  

Explanation/Detail:
I would like to column partition the entire database schema so that our "high sensitivity" data is processed and stored separately, perhaps in another instance in a different location.  This to improve security of our data, understanding that there would be a performance cost.

I would like to maintain the current schema for application compatibility purposes, just store the data differently for security reasons.
No. And it isn't just that this feature is not yet implemented, it is literally not possible to combine these two features in the way you're thinking.

Table partitions are row (record) based. You define a partitioning rule that determines which partition each record is stored in, based on a value stored in that record (for whichever column you've defined the rule). 

Data classification labels are column-based. They are simply meta-data (like extended properties) attached to columns in a table that categorize the sensitivity (or lack thereof) of the data stored in the entire column. These categorizations are used by some pre-defined reports, but otherwise don't impact the behavior of the database.

Some further thoughts:


SQL partitioning is used to break a table into separate chunks, but to still appear as the same logical table. You can put those chunks in different filegroups (and put the different filegroups on different physical disks), but they all still have to reside in the same SQL instance and database. 
If you are using the term "partition" less formally, sure, you could manually split a table into two tables based on sensitivity (say EmployeePublic and EmployeePrivate) with a 1-to-1 relationship, with different permissions or even encryption on each. You'd have to change your application queries, though, or create an Employees view that combines them back together in the way your application expects. This would be an entirely manual process, though, and has nothing to do with either the 2019 sensitivity flag or SQL table partitioning.