What is the difference between thin and thick JDBC drivers and how should I choose which to use?

Snowflake has thin, standard(thick?) and FIPS Java JDBC drivers. I dont need FIPS.

I had assumed that thin means lightweight, without required jars, and thick would be heavy and include any dependent jars.

Thus thin would be better if you want to make the app faster to load and have fewer dependency conflicts.

However, I have seen discussions about Oracle type 1 to 4 drivers which seem to imply the opposite.

What is the difference, and which should I choose for a Spring Boot app connecting directly to Snowflake via JDBC?

=== update 1 ===

I have tried both snowflake drivers. Maven could not resolve all the dependencies required for the "thin" driver, so to save time I went with their "standard" one which works out of the box with Maven + Spring Boot.

You've misunderstood the difference. The code contained in them is identical.

The 'fat jar' is a single jar that contains both the JDBC driver and all the other things that need to be on the classpath.

The 'thin jar' does not. That doesn't mean "it loads with fewer bytes" or "it has fewer features". No, it's the same thing. If you use the thin jar, you have to supply the dependencies. Which ones? Their pom file lists them out.

Generally fat jars are silly things; the number of projects that let you skip having some sort of proper dependency management is very small, and if you have proper dep management, 'thin jars' are strictly superior ('thin' is a weird name here; it is a name that exists solely to communicate 'NOT a fat jar' in a single word, and assumes folks know 'fat jar' is slang for 'a jar that contains everything'.

Fat jar downsides:

• If 2 different deps shipped as fat jar both e.g. internally use guava, then you now have 2 guavas. If they are different versions, you run into some real bizarre version conflicts.
• To be clear, fat jars do NOT allow multiple deps to each pull in their own version and use them independent of each other; if you want that, you need module systems such as OSGi; having the same dep in different fat jars is just asking for trouble, and is highly likely to occur unless you have a super simple project that only has a handful of deps.
• fat jars are pricey to make and ship. You make one small update and you have to build and then ship a 200MB or worse jar. Networks are getting faster and faster, but the time 'wasted' spamming 200MB worth of bits to a disk and then uploaded to your servers is not 0.

The advantage is that you don't have to 'figure out' how to get the deps of snowflake-thin available on the JVM that you want to run it on. That's kinda a weird advantage because it's (usually) not at all difficult to do such things; they ship a pom file.