Why JDBC still matters

JDBC is the standard bridge between Java and databases like MySQL, PostgreSQL, SQL Server and H2. ORMs are cute and helpful, but when you need predictable performance, explicit transactions and fewer surprises, JDBC is the plumbing you learn to love. Or at least tolerate.

Add the JDBC driver and dependency

Most modern build tools and IDEs fetch the driver when you declare the dependency. If your build tool does not want to cooperate, you can always grab the vendor jar and shove it on the classpath like a barbarian.

Example Maven dependencies

<!-- MySQL -->
<dependency>
  <groupId>mysql</groupId>
  <artifactId>mysql-connector-java</artifactId>
  <version>8.0.33</version>
</dependency>

<!-- PostgreSQL -->
<dependency>
  <groupId>org.postgresql</groupId>
  <artifactId>postgresql</artifactId>
  <version>42.6.0</version>
</dependency>

Obtain a Connection with DriverManager or a DataSource

Legacy code often uses DriverManager directly. That works, but for production you want a DataSource with connection pooling. Also note many drivers auto register themselves so Class.forName is usually optional now, but people still call it for nostalgia and superstition.

Class.forName("com.mysql.cj.jdbc.Driver");
try (Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/mydb", "user", "pass")) {
  // use conn
}

PreparedStatement for safety and speed

PreparedStatement prevents SQL injection and can improve performance by letting the driver cache execution plans. Use it instead of concatenating user input like a caveman.

String sql = "SELECT id, name FROM users WHERE email = ?";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
  ps.setString(1, email);
  try (ResultSet rs = ps.executeQuery()) {
    while (rs.next()) {
      int id = rs.getInt("id");
      String name = rs.getString("name");
      // map to objects or whatever you do with rows
    }
  }
}

Transactions and error handling

Wrap related statements in a transaction so you do not end up with partial updates and mysterious data guilt. Turn off auto commit, commit on success, rollback on failure, and always restore the original state if you changed it.

conn.setAutoCommit(false);
try {
  // multiple statements that must succeed together
  conn.commit();
} catch (SQLException ex) {
  conn.rollback();
  throw ex;
} finally {
  conn.setAutoCommit(true);
}

Connection pooling for real apps

If your app opens a new connection for every request you will learn the painful difference between local testing and production. Use a pool early. HikariCP is lightweight and fast and it plays nice with most JDBC drivers.

HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:postgresql://db:5432/mydb");
config.setUsername("user");
config.setPassword("pass");
HikariDataSource ds = new HikariDataSource(config);

try (Connection conn = ds.getConnection()) {
  // cheap to obtain, cheap to return
}

Quick checklist of best practices

• Prefer PreparedStatement over Statement to avoid injection and improve performance
• Always close ResultSet Statement and Connection. Try with resources makes this painless
• Use transactions for multi statement operations and rollback on errors
• Introduce connection pooling before your app meets real traffic
• Limit result sets and avoid SELECT star when you do not actually need every column
• Store credentials in environment variables or a secret manager not in code
• Map SQL types explicitly to Java types to avoid surprises with nulls and time zones

Parting advice

JDBC is not glamorous but it is reliable. Learn the basics now and your future self will send you a thankful snarky email. Use DriverManager for simple scripts, switch to a DataSource with connection pooling for production, and always treat SQL input like a suspicious guest.

Now go write some queries and try not to corrupt the database on your first commit.