To support modern versions of Hibernate, we need a JDBC 4 driver and we are looking to switch from our existing jtds driver http://jtds.sourceforge.net/ to Microsoft’s JDBC driver. Performance problems prevent us from switching.

When we run a load test simulating our toughest workload, Solarwinds DPA is recording 7 times the cpu/memory wait time, big spikes on SQL compiles / sec and an overall doubling of cpu usage overall. The performance problems occur because the MS driver does not support statement pooling and does not reuse PreparedStatements.

A older comment on your jdbcteam blog summarizes this need very well, I will copy/paste it here:

Brett.Wooldridge
December 1, 2015 at 4:47 pm
Hello JDBC Team,
I am the principal developer of HikariCP (https://github.com/brettwooldridge/HikariCP), the fastest growing connection pool for Java.
We frequently are asked to implement PreparedStatement caching within the pool, but our stance has always been and continues to be that caching belongs in the driver. On behalf of our MS SQL Server users, I would like to request the implementation of PreparedStatement caching.
A survey of the Top 5 databases (https://dzone.com/articles/10-most-popular-db-engines-sql) leaves only SQL Server out without prepared statement caching.
Ironically, SQL Server's JDBC driver has a property, disableStatementPooling, which defaults to *true. Only true is supported currently (setting to false will throw an exception).
It was literally HikariCP's stand against placing responsibility of caching in the pool that prompted PostgreSQL to implement their very excellent solution (pgjdbc/pgjdbc#308).
The PostgreSQL implementation took one developer 3 days from start to finish.
In this new Satya Nadella era, isn't this the time for Microsoft to prove that it can be just as agile as the open source databases? The 6.0 Preview is the perfect chance to introduce this long needed feature.
Regards,
Brett Wooldridge

More from Brett regarding Statement Caching and why it is needed at the driver is on the HikariCP site:
https://github.com/brettwooldridge/HikariCP

Statement Cache
Many connection pools, including Apache DBCP, Vibur, c3p0 and others offer PreparedStatement caching. HikariCP does not. Why?
At the connection pool layer PreparedStatements can only be cached per connection. If your application has 250 commonly executed queries and a pool of 20 connections you are asking your database to hold on to 5000 query execution plans -- and similarly the pool must cache this many PreparedStatements and their related graph of objects.
Most major database JDBC drivers already have a Statement cache that can be configured, including PostgreSQL, Oracle, Derby, MySQL, DB2, and many others. JDBC drivers are in a unique position to exploit database specific features, and nearly all of the caching implementations are capable of sharing execution plans across connections. This means that instead of 5000 statements in memory and associated execution plans, your 250 commonly executed queries result in exactly 250 execution plans in the database. Clever implementations do not even retain PreparedStatement objects in memory at the driver-level but instead merely attach new instances to existing plan IDs.
Using a statement cache at the pooling layer is an anti-pattern, and will negatively impact your application performance compared to driver-provided caches.

I wrote simple PreparedStatement test programs that execute a simple select PreparedStatement on AdventureWorks2014 10k times on a SQL 2016 instance. Jtds completed in 19 seconds, the ms driver in 35 seconds and there was significantly more load placed onto the SQL Server instance. You can see why in a SQL Profiler trace.

Microsoft:

The MS driver is constantly preparing and unpreparing a statement on every execution. I used mssql-jdbc-6.1.4.jre7-preview.

jTDS:

Jtds prepares things once and then reuses the PreparedStatement.

The source of those tester programs are attached if they are of value to anyone. The postgres driver implemented statement caching a couple years ago and it could be used if you want ideas on how to implement it: pgjdbc/pgjdbc#319

jdbc.zip