View the original community article here
Last tested: Jan 17, 2019
TLDR: Wherever the PDTs are located, they must remain accessible and readable by the default (non-PDT) connection. SO a “separate” db likely won't work as the PDTs would source from and be written to the separate db, but be inaccessible to the non-override connection.
Writing PDTs to a different database using the PDT override feature is only supported for systems that support “databases” as the superset namespace of schemas. For example, Snowflake has a concept called “warehouse”--multiple warehouses can be configured to access the same underlying database storage but have different CPU/memory resources, so in this sense, specifying a different data "warehouse" may work.
For most other databases, although you'll find that it is possible to use the PDT Overrides column to configure PDT processes to *write* to a separate database, if the PDTs are not visible to your default (non-override) connection, you won’t be able to query them. This will result in read errors when querying these tables like "Invalid object name" or "relation does not exist". Override connections is more about specifying a different user/various other params e.g. for workload management tuning.
This content is subject to limited support.