I run Visual Studio 2012 and I'm new to SSIS. I attempted to install SSDT-BI (June 2013 version) in order to research SSIS, but I was unable to complete the install with my default instance because the architectures don't match--my server is x64 while the installer is x86. There doesn't appear to be an x64 version of the installer.
Does SSDT-BI not support x64 databases?
On
Recently I had to install SSDT BI for a sql 2014 instance. The download available msdn https://www.microsoft.com/en-us/download/details.aspx?id=42313 says its supported for both 32-bit (x86) & 64-bit (x64) architecture. If we install SSDT-BI as an add on feature to an existing sql instance the installation fails with error: Rule evaluation message: The CPU architecture of installing feature(s) is different than the instance specified. To continue, add features to this instance with the same architecture. I referred this link https://danieladeniji.wordpress.com/tag/the-cpu-architecture-of-installation-features-is-different-than-the-instance-specified-to-continue-add-features-to-this-instance-with-the-same-architecture/ to work around this issue. Installing SSDT-BI as as new instance completed without any errors.
On
If you're using x64 bit SQL Server, make sure select "new instance" on "Installation Type" page in install wizard. check out http://picnicerror.net/development/sql-server/installing-sql-server-data-tools-business-intelligence-for-visual-studio-2013-03-13/
SQL Server Integration Services, SSIS, covers a whole lot of territory. I'll discuss what's relevant to this question of 32 vs 64 bit-ness.
Installation
As you discovered, the installer is stupid but you typically only need to use it once or twice in a machine's lifetime. I'm ok with this as I'd rather them spend development dollars are the product and not the packaging.
Following SO best practice, the important piece from the externally referenced site is
Package
An SSIS package is a deliverable unit of work. It is an file with a
.dtsxand internally is a bunch of XML.Development
Typically, development of SSIS packages is completed by using Visual Studio. Whether you call it BIDS, SSDT or just Visual Studio, it's the same thing. There are registered templates for SSIS as well as all the toolbox entries that get put onto a machine during installation. That stuff supports the design time aspect. Visual Studio itself is still a 32 bit executable. Therefore, when you are creating packages using Visual Studio, the editor you are using to create a package is a 32 bit entity. Unless you are creating a multi-gig package, this shouldn't be an issue.
And one might argue that if you get a multi-GB package that even if XML is a bloated storage mechanism, you are "doing it wrong" ;)
On a final note, development of packages is not constrained to Visual Studio. There is a paid-for product, Mist, that uses Biml (a domain specific language that describes BI objects) to generate SSIS packages. Looking at your SO history, you look like you have some PowerShell chops, you can use PowerShell to modify SSIS packages or flat out create them. There the EzAPI to help with the COM side of generating packages.
Execution
The execution of a package can be from a 32 or 64 bit executable. See How to execute dtsx packages through command line By default, the packages will execute in 64 bit mode from Visual Studio. The design time is 32 bit but run time is 64 bit. This always makes for great entertainment when folks use 32 bit drivers (Excel/Jet/ACE) and the packages design just fine but blow up when they run. The other gotcha of 32/64 driver is the creation of DSNs as there are 2 different DSN "spaces" See 32-bit informix drivers in 64-bit windows server 2008 are unavailable
In 2012, if you use the Project Deployment Model, the packages are stored in the SSISDB catalog. SQL Server only comes in 64 bit flavors but again you can call the 32 bit runtime for SSIS from the catalog by specifying the appropriate Parameter.