Why do we implement Database.batchable interface or what happens when we implement Database.batchable interface?

Database.Batchable<T> is an interface from the Database system namespace. Implementing it does two things:

1. Contracts your class to provide the three lifecycle methods — start, execute, finish — with their exact signatures.
2. Registers your class as eligible for Database.executeBatch(), the entry point the platform uses to schedule async, chunked execution.

Without the interface, Database.executeBatch(new YourClass()) won’t compile — Salesforce wouldn’t know your class is a batch job.

The interface contract

public interface Database.Batchable<T> {
    Iterable<T> start(Database.BatchableContext ctx);
    void execute(Database.BatchableContext ctx, List<T> scope);
    void finish(Database.BatchableContext ctx);
}

(Conceptually — the actual definition is in the platform, not Apex source.)

Your class declares which type T is. Almost always it’s sObject:

public class MyBatch implements Database.Batchable<sObject> {
    public Database.QueryLocator start(Database.BatchableContext ctx) { ... }
    public void execute(Database.BatchableContext ctx, List<sObject> scope) { ... }
    public void finish(Database.BatchableContext ctx) { ... }
}

You can also use Database.Batchable<MyCustomApexType> if your data isn’t sObjects, but sObject is by far the common case.

What “implementing” actually does

When you write implements Database.Batchable<sObject>, the Apex compiler verifies your class has exactly these three methods with the correct signatures. Miss one, get the wrong return type, or use a wrong parameter type, and the class won’t compile.

This contract is what allows Database.executeBatch(new MyBatch()) to be type-safe: the platform knows it can call start, get back a QueryLocator or Iterable, chunk the results, call execute for each chunk, and call finish at the end.

Why the interface model (vs a base class)?

Salesforce uses interfaces over abstract base classes throughout the async APIs:

• Database.Batchable<T> — batch
• Queueable — queueable
• Schedulable — scheduled
• Database.AllowsCallouts — batch callout opt-in
• Database.Stateful — batch state opt-in
• Database.RaisesPlatformEvents — batch publishing platform events

Interfaces let you compose capabilities. A single class can implement Database.Batchable<sObject>, Database.AllowsCallouts, Database.Stateful, and Schedulable all at once — declaring “I’m a stateful batch that does callouts and can also be scheduled.”

public class MegaBatch implements
    Database.Batchable<sObject>,
    Database.Stateful,
    Database.AllowsCallouts,
    Schedulable
{
    // ... start, execute, finish, plus execute(SchedulableContext)
}

This composability would be hard with a single base class.

What you get for free

Once the platform recognizes your class as Database.Batchable:

• Chunked transactions — each execute runs in its own transaction with its own governor limits.
• Up to 50 million records in start via QueryLocator.
• Automatic enqueuing — Database.executeBatch returns immediately; the platform handles scheduling.
• Monitoring — every job creates an AsyncApexJob record visible in Apex Jobs UI.
• Email on uncaught exceptions — Salesforce notifies the apex exception recipients.

None of those are things you have to code; they come from implementing the interface and using the official entry point.

Common interview follow-ups

• What if I implement only two methods? — Compile error.
• Can I override the signatures? — No. They’re fixed by the interface.
• What’s the difference between Database.Batchable<sObject> and Database.Batchable<Account>? — The T parameter only affects the type-hint in execute(... List<T> scope). Using sObject is more flexible; using a concrete type is slightly more type-safe.

Verified against: Apex Developer Guide — Database.Batchable Interface. Last reviewed 2026-05-17.