Hi Brandon, thanks for reaching out on this forum. 

If each TimeXtender target database is on the same SQL Server Instance the recommended approach is using Direct Read-Matching Server. This will have a significant performance gain over ADO or SSIS and does not require TimeXtender to be installed on the same server. 

Will this approach work for you? 

Joseph, hello.  That setting may work.  Currently that feature is disabled.  I planned on bringing that setting to their attention as I had read about it.  At the moment, it appears the main concern is throughput after the server split.  This direct read - matching server is not a setting on the business unit database.  All the databases, including the BU, are on the same server.  Does setting the Direct Read - Matching Server on the data warehouse data connections include the data read from the business unit database as well?  Not into the BU database, but from...

Hi Brandon we have been using Direct Read since it was first introduced and that's exactly how it works.

From BU to DW data is transferred directly by the SQL server via a stored procedure that does INSERT INTO (your dw table) FROM (your stage table), no intervention needed from TX.

Where ADO is still needed is from Source to BU. But that's only once via the server where TX resides. All the "heavy lifting" afterwards is done by the SQL server.

I think I follow you here, Calmco Support, and I appreciate the response.  I am not familiar (yet) with many of these technical ins and outs, so your comment brings a question to mind.  Do you think there would be much difference in performance between using ADO.NET to populate the BU database on the same server as the TX application, versus using ADO.NET to populate that same BU database but with TX installed on its own server?   

Hi Brandon, No. I believe the performance difference you would see in your example would be negligible.