As per documentation, it's only supported in Splunk Enterprise (6.1 or later), so my guess will be that we can't install it on UF.
So if install db connect app in search head and perform the read operations in it will it impact the performance (the size of the database is very large)
It'll affect the performance. That's why we, and may be many others, create a separate job server instance for these kind of jobs, basically a dedicated search head.
Old question, but I'll toss on my response.
Setup a 'Heavy Forwarder'. It is a full enterprise 6.x server, but you trim it back so that Search isn't used. You can set it to 'index and forward', then pump your database server (DB Connect) data into it and have Splunk forward that to the far side (where ever that may be, even if it is only 6 inches away).
This lets your search head be search heads, and your data gatherer (forwarder) do the hard work on a different box.
For a lot of people the idea of 'more boxes' is uncomfortable. If you have a small shop and not a lot of data you want to bring into Splunk, then an all in one box, or a combo Search Head / DB Connect box can work. As the value of that searchable data out paces the single boxes ability to keep up, you may be able to find the budget for more servers. Remember that you are paying for capacity. So all these extra forwarders and search heads have a smaller price than you might have realized. Plus, you might find the size of a forwarder is a lot smaller then the big box you have your indexer running one.
My first 'production data' box was a single all in one with DB Connect pulling data every 60 seconds from a logging database on MS SQL Server. But it doesn't have much else going into it so it works just fine.
My latest stack will use a distributed model to deal with the influx of data. I am looking at 7 different Heavy Forwarders running a variant of what my 'all in one' box was doing (in 7 different environments), plus a whole lot of servers pushing data into HTTP Event Collection end points. On top of that add the desire to index Server performance data and error / event logs from a web farm. So a single all in one box would likely choke on that incoming data, let alone struggle to act as a search head too.