Skip to content

CONCEPT Cited by 1 source

ReadPartialCommits (proposed isolation level)

ReadPartialCommits is a proposed isolation level — not shipped in any production database as of the 2026-04-21 ingest — introduced by Sugu Sougoumarane in his 2020 canonical PlanetScale post on "Pitfalls of isolation levels in distributed databases." It is designed for applications that run under concepts/atomic-distributed-transaction|2PC but are willing to tolerate reading the partially-committed state of an in-flight distributed transaction.

Definition

"It may be worth introducing a new isolation level like ReadPartialCommits. Note that this is different from ReadUncommitted where you may read data that may eventually be rolled back." (Source: sources/2026-04-21-planetscale-pitfalls-of-isolation-levels-in-distributed-databases.)

Formal shape:

  • Reads see only committed rows on each participant — unlike READ UNCOMMITTED which permits reading uncommitted writes.
  • Reads do not wait for all 2PC participants to complete their commit phase before exposing locally-committed rows. A reader can observe the first commit before the second has landed.
  • The distinction from READ COMMITTED: a standard READ COMMITTED reader in a 2PC-aware database blocks (or re-reads) until all participants of a concurrently- committing distributed transaction have landed their commits — preserving cross-shard atomic visibility. Under ReadPartialCommits, the reader proceeds immediately on each shard as if the cross-shard atomicity did not apply to them.

Why propose a new level at all

Sougoumarane's motivation is the coupling cost that standard 2PC imposes on visibility:

For example, let us assume that only the first commit of a 2PC transaction has succeeded and the second commit is delayed. If the application has read the effects of the first commit, then the database must prevent the application from reading the rows of the second commit until completion. Flipping this around, if the application has read a row before the second commit, then it must not see the effects of the first commit.

The database has to do additional work to support the isolation guarantees for distributed transactions. What if the application could tolerate these partial commits? Then we are doing unnecessary work that the application doesn't care about.

ReadPartialCommits lets a 2PC-era application opt out of the in-flight-visibility coordination machinery while retaining the core ACID guarantees within each participant.

Where it fits in the hierarchy

Canonicalised ordering (weakest → strongest):

Level Reads committed rows only Waits for cross-shard 2PC completion
READ UNCOMMITTED no n/a
ReadPartialCommits yes no (the novel axis)
READ COMMITTED yes yes (when 2PC is in use)
REPEATABLE READ / SI yes yes
SERIALIZABLE yes yes

The novel axis is the second column. ReadPartialCommits sits between READ UNCOMMITTED (which weakens row-level commit visibility) and READ COMMITTED (which preserves both row-level and distributed-transaction-level commit visibility).

Application shape that benefits

Applications where cross-shard transactions are used for operational convenience (e.g. administrative housekeeping, multi-table bookkeeping writes) rather than because the cross-shard atomicity matters for user-visible correctness. For these cases the partial-commit visibility is acceptable because:

  • The user-visible read path does not correlate data across the shards the 2PC spans.
  • Any temporary partial-commit-visible state is reconciled by the time the transaction fully completes, and no downstream reader acts on the window.

This is a narrow set of applications — most use cases that demand cross-shard atomicity are precisely the ones that cannot accept partial-commit visibility.

Status as of 2026-04-21

  • Not implemented by any major database. Postgres, MySQL, Oracle, SQL Server, Spanner, CockroachDB, and TiDB all support only the four ANSI levels (plus snapshot variants) — none has shipped a ReadPartialCommits equivalent.
  • Pedagogical design-space pointer. The proposal is canonical on the wiki as a design-space observation for distributed-database operators facing the 2PC visibility- coordination tax, not as a selectable mode.
  • Vitess + others sidestep via topology. Rather than weaken the isolation level, Sougoumarane's recommendation (in the same post) is "avoid distributed transactions by keeping related rows within the same shard." Vitess's ordered commit without 2PC mechanism is a further sidestep — it provides a weaker-than-2PC atomicity contract by design, making the visibility-coordination tax a non-issue.

Caveats

  • Proposal, not a standard. The post explicitly frames this as "it may be worth introducing" — exploratory, not authoritative. No follow-up specification work has shipped.
  • Precise semantics of what "partial" means are underspecified. In particular: if the 2PC transaction ultimately rolls back rather than completing the second commit, does the ReadPartialCommits reader need to see the rollback of the first commit they may have already observed? The post does not address this, and the answer is load- bearing for correctness.
  • Low-priority design-space point. Systems pursuing scalable distributed databases have largely chosen either (a) "don't do cross-shard 2PC" (the Vitess / ordered- commit direction) or (b) "use a globally-consistent clock" (Spanner / CockroachDB direction). ReadPartialCommits occupies a third corner that few designers have found compelling in practice.

Seen in

Last updated · 550 distilled / 1,221 read