The job repository is required to run spring batch but it is one of those things that requires a bit of work to actually deliver any value (e.g. setting up spring batch admin or writing your own ui). In practice in most projects that I've seen that use Spring Batch the job repository is purely a write only thing that tends to be ignored completely. You're required to have it, nobody ever looks at it. Digging around in tables using an sql client to find logs with errors, warnings, and stack traces, is not a thing if you set up logging properly and doing logging properly is a hard requirement for any serious server side business.

IMHO, making the job repository optional would be a good thing given that it adds a lot of complexity. Most projects simply don't need it. And most projects that do need it (e.g. multi node batch clusters) should probably be looking at other technologies as well that are actually intended to provide cross cluster state management (e.g. Zookeeper). Also, at that point you are probably better off looking at things like Spring Cloud, hadoop or similar solutions. Spring batch sort of is a stepping stone towards those kinds of solutions.

Some things to be aware off:

• Spring batch will create and fill tables with information that you probably want in a different place than your production database.
• If you do end up with spring batch tables in your production db (e.g. because provisioning an extra db for tables you fundamentally don't care about would be overkill), you'll probably want to make sure these tables are part of your db migration scripts.
• You may also want to consider cleaning up data accumulated in these tables regularly, especially if you never actually do anything with it.
• By default jobs can run only once, you actually have to configure them to be able to run multiple times. It actually stores in the job repository that it already ran and by default will do nothing if you run something a second time. This "feature" has caught me by surprise on multiple occasions. The solution is adding a .incrementer(new RunIdIncrementer()) to your jobs.
• Spring batch assumes that your jobs and steps are going to be distributed in a cluster (even when that is never going to be a thing for most projects). Therefore, the job repository is effectively the only way to pass around information (via the execution contexts, which get persisted).

After I posted I found Mahmoud’s answer and I was able to implement it. Thank you!

BatchConfig.java

@Configuration
@EnableAutoConfiguration(exclude = {DataSourceAutoConfiguration.class})
public class BatchConfig {

  @Bean
  public PlatformTransactionManager transactionManager() {
    return new ResourcelessTransactionManager();
  }

  @Bean
  public JobRepository jobRepository() {
    return new ResourcelessJobRepository();
  }

  @Bean
  public JobLauncher jobLauncher(JobRepository jobRepository) {
    TaskExecutorJobLauncher jobLauncher = new TaskExecutorJobLauncher();
    jobLauncher.setJobRepository(jobRepository);
    return jobLauncher;
  }
}

JobConfig.java

@Configuration
public class JobConfig {

  @Bean
  public Job taskletJob(JobRepository jobRepository, Step step) {
    return new JobBuilder("taskletJob", jobRepository)
      .start(step)
      .build();
  }

  @Bean
  public Step sampleStep(JobRepository jobRepository, PlatformTransactionManager transactionManager) {
    return new StepBuilder("sampleStep", jobRepository)
      .tasklet(new SampleTasklet(), transactionManager)
      .build();
  }
}