As fas as I understand, the partitioning is rooted at the application level, by preventing cross-domain joins:
> Building on top of schema domains, two new SQL linters enforce virtual boundaries between domains. They identify any violating queries and transactions that span schema domains by adding a query annotation and treating them as exemptions. If a domain has no violations, it is virtually partitioned and ready to be physically moved to another database cluster
Table-level partitioning doesn't help with this (AFAIU), as queries access multiple tables anyway (without app-level changes).
The standand db-level feature closest to what they're doing, if somebody "wants to try this at home", is probably tablespacing (or separate dbs, in the next step).
I see some inspiration from microservices (separation of models/storages), except that they're (I suppose) keeping the monolith approach.
You can kind of do the same thing with SQL server table partitions but it would largely rely on the original data model being very clean. Depending on how old that code base is, and how experienced the developers were, that might not have been an option I suppose.
> Building on top of schema domains, two new SQL linters enforce virtual boundaries between domains. They identify any violating queries and transactions that span schema domains by adding a query annotation and treating them as exemptions. If a domain has no violations, it is virtually partitioned and ready to be physically moved to another database cluster
Table-level partitioning doesn't help with this (AFAIU), as queries access multiple tables anyway (without app-level changes).
The standand db-level feature closest to what they're doing, if somebody "wants to try this at home", is probably tablespacing (or separate dbs, in the next step).
I see some inspiration from microservices (separation of models/storages), except that they're (I suppose) keeping the monolith approach.