BEGIN IMMEDIATE

How BEGIN IMMEDIATE changes SQLite transaction timing

BEGIN IMMEDIATE takes the write lock before the transaction reaches its first write statement. That changes the timing of contention: instead of discovering write conflict later, SQLite resolves it at transaction start. The result is a more predictable boundary for workloads that coordinate activity across multiple attached databases.

This matters because the lock is acquired early, not because the transaction becomes inherently faster. In practice, the statement is useful when an application wants to know immediately whether it can proceed with a write path, rather than letting work accumulate and failing at a later point.

Why deferred locking can surprise multi-database workloads

SQLite deferred transactions wait until the first write to request the write lock. In a single-database flow that may be harmless, but across attached databases it can create awkward lock ordering if one part of the work reads or prepares state before another part needs to write. BEGIN IMMEDIATE reduces that uncertainty by making the write intent explicit up front.

The main design trade-off is that the transaction reserves write access earlier, which can increase contention for other writers. That is often acceptable when predictability matters more than optimistic concurrency, especially in systems that need consistent sequencing across related database files.

What BEGIN IMMEDIATE protects against

BEGIN IMMEDIATE is best understood as a concurrency-control choice, not a data-integrity feature by itself. It helps avoid deadlocks and lock-order surprises that arise when a deferred transaction reaches its first write only after other work has already begun. By forcing the write lock at the start, it narrows the gap between intent and enforcement.

That also makes failure easier to reason about. If the write lock cannot be obtained, the application learns that immediately and can retry, back off, or choose another path before doing additional work that would later have to be abandoned.

When to prefer it over other transaction starts

BEGIN IMMEDIATE is a good fit when the application knows it will write and wants early confirmation of that ability. It is especially relevant when the transaction spans several attached databases, or when the code must avoid acquiring locks in a way that depends on execution timing.

It is less useful when the workload is highly read-heavy or when a later write is only occasional, because reserving the write lock too early can reduce concurrency. In SQLite, the practical question is not whether the transaction is “stronger”, but whether earlier lock acquisition matches the workload’s ordering needs.

Risk and Threat Considerations

BEGIN IMMEDIATE mainly addresses operational contention risk, not adversarial threat. If an application relies on deferred locking in a multi-database workflow, the most likely failure mode is a late lock acquisition error or an avoidable deadlock-like stall when the write path finally begins.

Failure mechanism: A transaction performs reads or preparatory work first, then tries to write after another session or attached database has already affected lock availability, creating lock-order inversion or a failed write transition.

Impact: Work can be wasted, retries become more frequent, and concurrent writers may experience unnecessary blocking or inconsistent transaction timing.

Practitioner Guidance

Why practitioners should care: Use BEGIN IMMEDIATE when write intent is known early and the system benefits from deterministic lock acquisition. That is usually the right choice for workflows where a late conflict would be expensive or hard to recover from.

Common misunderstanding: BEGIN IMMEDIATE does not remove locking pressure, it changes when that pressure is paid. If concurrency is the priority, it may be the wrong choice even though it reduces surprise.

Practitioner takeaway: Treat it as a coordination tool for predictable write sequencing, especially when attached databases make lock order more important than optimistic start-up behavior.

Related resources from NHI Mgmt Group

• How do most NHI breaches actually begin, despite the sophistication often attributed to attackers?
• Why do AI agent security risks require immediate attention?
• When does secret rotation reduce risk more than immediate revocation?
• How can organisations decide which discovered apps need immediate action?