Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
PBKDF2 impact on SQL Logins in SQL Server 2025 (and building a tool to test it)
(Post rave comedown)
(SKIP TO THE END FOR THE RESULTS)
Mid last year, I was working on a big side project, and I noticed that the completion times on health check operations on a pre-release version of SQL Server 2025 were taking longer. I put this down to coincidence, human error, or I was just paranoid. It turns out I was not being paranoid, and logins were actually slower over SQL authentication. See the below from Microsoft (PBKDF2 hashing algorithm can affect login performance):
I learned of this from Aaron Bertrand via Brent’s blog
I wanted to quickly measure the differences between SQL Server 2025 and prior versions on my own lab environment, so I decided to use this as an excuse to play with GLM-4.7 and OpenCode to knock up a quick Go program to test it. I will leave any code in the APPENDIX if you want to run it yourself.
Tools
Here are the tools I used to build our small test program:
- OpenCode 1.0.23
- GLM-4.7 Z.AI Coding Plan
- VS Code
- WSL2
Building the program
I ran with the following basic prompt:
As this is pretty much the most basic of database applications, GLM-4.7 one-shotted something usable:
All done in 45 seconds:
Testing it from VS Code:
Nice, it worked. As this tool is just for my own use, I am not concerned with coding idioms, best practices or security.
We can do a little better and add an ‘attempts’ switch so I don’t have to manually execute it over and over again:
Off it went:
All sorted:
It works:
My laziness continued as I asked it to give me the mean average once the results were fetched:
More changes:
It works:
We can now run some tests on SQL Server.
Test results
Here are the connection times over SQL authentication on the following versions of SQL Server:
- SQL Server 2012
- SQL Server 2014
- SQL Server 2016
- SQL Server 2017
- SQL Server 2019
- SQL Server 2022
- SQL Server 2025
SQL logins are indeed slower on SQL Server 2025:
It is repeatable, and the difference is obvious:
eg SQL Server 2019:
SQL Server 2025
Please note that for SQL Server versions 2012 and 2014, I hardcoded encrypt=disable in the connection string to avoid the following:
Conclusion
In my testing, PBKDF2 does make an appreciable difference to SQL Server login times when using SQL authentication.
Best practice in this case, according to Microsoft, is to ensure connection pooling is used.
As an aside, OpenCode and GLM-4.7 made this experiment trivially easy for a very low cost. Whilst our little program does enough for testing purposes, it is not a real application and has not been properly tested, etc.
Resources
APPENDIX
package main
import (
"database/sql"
"flag"
"fmt"
"log"
"time"
_ "github.com/denisenkom/go-mssqldb"
)
func main() {
server := flag.String("server", "", "SQL Server address")
user := flag.String("user", "", "Username")
password := flag.String("password", "", "Password")
database := flag.String("database", "", "Database name")
attempts := flag.Int("attempts", 1, "Number of connection attempts")
flag.Parse()
if *server == "" || *user == "" || *password == "" || *database == "" {
log.Fatal("All parameters (server, user, password, database) are required")
}
connString := fmt.Sprintf("server=%s;user id=%s;password=%s;database=%s;encrypt=disable", *server, *user, *password, *database)
var totalTime int64
var successfulConnections int
for i := 0; i < *attempts; i++ {
start := time.Now()
db, err := sql.Open("mssql", connString)
if err != nil {
log.Printf("Connection failed: %v (0ms)", err)
return
}
err = db.Ping()
if err != nil {
db.Close()
log.Printf("Connection failed: %v (0ms)", err)
return
}
elapsed := time.Since(start)
db.Close()
log.Printf("Connection successful: Connected to %s (%dms)", *server, elapsed.Milliseconds())
totalTime += elapsed.Milliseconds()
successfulConnections++
}
if successfulConnections > 0 {
average := totalTime / int64(successfulConnections)
log.Printf("Average connection time is %dms", average)
}
}