I recently spent many painful hours debugging a Quartz Scheduler issue in a Spring Boot application using PostgreSQL.

Everything looked correct on the surface:

• Quartz tables were created successfully
• Jobs were inserted into QRTZ_* tables
• Triggers were visible in the database
• The application started without errors

Yet the jobs never executed.

The logs were filled with errors like:

 Bad value for type long : \x Cannot convert the column of type BYTEA to requested type long Couldn't retrieve trigger 

At first glance, this looks like a PostgreSQL schema or BYTEA issue. It is not.

This is a Spring Boot + Quartz configuration trap that is very easy to fall into.

Short Answer (TL;DR)

Use this in Spring Boot:

 org.quartz.jobStore.class: org.springframework.scheduling.quartz.LocalDataSourceJobStore 

Do NOT use this directly:

 org.quartz.jobStore.class: org.quartz.impl.jdbcjobstore.JobStoreTX 

Spring Boot already wraps JobStoreTX internally. Forcing it manually breaks job execution.

Why This Error Is So Confusing

This issue is difficult because:

• Quartz schema initializes correctly
• Jobs are persisted
• Triggers exist
• No startup failure occurs
• Execution fails silently at runtime

Most developers assume it is a PostgreSQL or Flyway problem. It is not.

Why JobStoreTX Does Not Work in Spring Boot

Quartz (Plain Java)

In vanilla Quartz, configuration looks like this:

 org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX 

Quartz then:

• Creates its own DataSource
• Manages JDBC connections
• Controls transactions itself

This works only outside Spring.

Spring Boot Quartz Is Different

Spring Boot:

• Manages the DataSource
• Manages transactions
• Wraps SchedulerFactoryBean
• Integrates Quartz into the Spring lifecycle

Internally, Spring Boot uses:

 LocalDataSourceJobStore -> delegates to JobStoreTX 

This is intentional.

What Goes Wrong When You Force JobStoreTX

When you manually configure:

 org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX 

Quartz attempts to:

• Create its own unmanaged DataSource
• Deserialize job data outside Spring
• Bypass Spring transactions

Meanwhile Spring Boot already has its own DataSource and transaction manager.

The result:

• Double DataSource initialization
• Broken serialization
• BYTEA to LONG conversion errors
• Triggers fail to load
• Jobs never execute

Often with no clear startup error.

The Correct Spring Boot Configuration

 quartz:

   job-store-type: jdbc

   jdbc:

     initialize-schema: always

   properties:

     org.quartz.jobStore.class: org.springframework.scheduling.quartz.LocalDataSourceJobStore

     org.quartz.jobStore.driverDelegateClass: org.quartz.impl.jdbcjobstore.PostgreSQLDelegate

     org.quartz.jobStore.isClustered: true

     org.quartz.jobStore.clusterCheckinInterval: 10000

     org.quartz.scheduler.instanceId: AUTO

     org.quartz.scheduler.instanceName: ClusteredQuartzScheduler

     org.quartz.threadPool.threadCount: 5

This configuration:

• Uses Spring-managed DataSource
• Works correctly with PostgreSQL
• Supports clustering
• Avoids BYTEA corruption
• Executes jobs reliably

Why LocalDataSourceJobStore Works

LocalDataSourceJobStore:

• Uses Spring’s DataSource
• Participates in @Transactional
• Delegates safely to JobStoreTX
• Handles serialization correctly

This class exists specifically for Spring.

Why Jobs Are Removed from the Database After Execution

This is correct behavior.

Quartz separates:

• JobDetail – job definition
• Trigger – execution schedule

For one-time jobs:

1. Job is stored
2. Trigger fires
3. Trigger is deleted
4. Job may also be deleted if not durable

This prevents database bloat and is expected.

When Quartz Is the Right Tool

• Email sending
• Background tasks
• Delayed execution
• Scheduled processing

Quartz is a scheduler, not a message queue.

Final Takeaway

• Do not configure JobStoreTX manually in Spring Boot
• Always use LocalDataSourceJobStore
• Let Spring manage Quartz
• The BYTEA error is a configuration issue, not PostgreSQL

Once configured correctly, Quartz is stable and production-ready.

If you are using Spring Boot with Quartz and PostgreSQL, this configuration will save you hours of debugging.