Q.Lamport clock vs vector clock: what each one can actually prove

Every database vendor sells you "ordering". Google bought GPS receivers and atomic clocks to get it. The 1978 math underneath costs nothing, and it is worth knowing what it can and cannot prove before you pay for more.

Key numbers

The problem both clocks solve

Two servers write to the same record. Which write came first? You cannot just compare their wall clocks, because their clocks disagree. We checked ours while writing this: our Windows 11 PC was a full second behind every public time server we asked, because its Windows Time service was not running.

21 raw SNTP queries from our PC to 5 public time servers, Oct 25 2026, 8:12 PM ET. Round trips were 6.5 to 58 ms, so the error is the clock, not the network.

A one-second gap means any reply our PC sends within a second of receiving a message is stamped earlier than the message it answers. Sort by timestamp and the answer shows up before the question. That is the bug Leslie Lamport fixed on paper in 1978, without touching a physical clock.

How a Lamport clock works

Lamport's rules, from Time, Clocks, and the Ordering of Events in a Distributed System:

1. Each process keeps one integer counter and adds 1 before every event.
2. Every message carries the sender's counter.
3. On receipt, the receiver sets its counter to the larger of its own and the message's, plus 1.

That guarantees what Lamport called the Clock Condition: if a happened before b, then C(a) is less than C(b). Break ties by process ID and you get a total order of every event in the system, which is enough for mutual exclusion, replicated logs and leader election. Lamport himself calls it "my most often cited paper" and adds, dryly, that "many computer scientists claim to have read it."

What you do not get is the converse. C(a) less than C(b) does not mean a caused b. Two events on machines that never talked still get different numbers, and the clock cannot tell you so.

How a vector clock works

A vector clock, worked out independently by Colin Fidge and by Friedemann Mattern, keeps one counter for every process:

1. Process i adds 1 to its own slot before each event.
2. Every message carries the whole vector.
3. On receipt, take the larger value in every slot, then add 1 to your own.

To compare two events, compare the vectors slot by slot. If every slot of A is less than or equal to B's, A happened before B. If B is ahead in one slot and A in another, they are concurrent: neither could have caused the other. That one extra answer is the whole point.

Three servers, seven events. Lamport puts b (2) before e (3). The vectors show they are concurrent: neither server knew about the other's event. Diagram by Tensorust.

What we found when we ran both

We simulated 2,000 events spread across 2 to 100 processes, 5 runs at each size (35 runs, about 2 million event pairs each). Each step, a random process either received a waiting message or did a local event, and 35% of those local events also sent a message to a random peer. We tagged every event with both clocks, then used the vectors as ground truth.

• With 2 nodes, 1.0% of pairs were concurrent and a Lamport order was causal 99.0% of the time. Lamport is basically right.
• With 10 nodes, 15.6% of pairs were concurrent and the Lamport order was causal 84.7% of the time.
• With 100 nodes, 94.9% of pairs were concurrent and the Lamport order was causal just 5.3% of the time.
• At every size, the Lamport clock still put a strict order on 95.5% to 98.1% of the concurrent pairs. It never says "I don't know". It just picks.

Our setup is a model, not your system: fixed total events means each node does less as nodes are added, which pushes concurrency up. But the direction is the lesson. The more independent writers you have, the more a single counter's "before" is a coin you flipped yourself.

The price of knowing: vector size

Vector clocks grow with the number of writers. At 8 bytes per counter, 100 nodes means 800 bytes riding on every version of every record, against 8 bytes for a Lamport time. Real systems pick a side:

• Amazon Dynamo used vector clocks to keep conflicting shopping cart versions and let the application merge them. Its paper reports that over 24 hours, 99.94% of requests saw exactly one version and 0.00057% saw two.
• Apache Cassandra went the other way. Its docs say that unlike Dynamo, it "uses a simpler last-write-wins model where every mutation is timestamped". Cheaper, and the later wall-clock time wins a conflict, even when that clock is a second slow like ours.
• Google Spanner made wall clocks honest instead: TrueTime uses GPS and atomic clocks, keeps uncertainty around 1 to 7 ms, and makes each commit wait out at least twice that uncertainty.
• Hybrid logical clocks (Kulkarni and colleagues, 2014) take physical time plus a small counter, respect cause and effect like a Lamport clock, stay close to NTP time, and fit in 64 bits. CockroachDB runs on this idea and, per its docs, crashes nodes whose clocks drift past 500 ms by default rather than risk inconsistent reads.

Where this shows up in your IDs

Time-ordered IDs are Lamport's problem in disguise. RFC 9562 calls monotonicity "the backbone of time-based sortable UUIDs", then lets implementations alter the timestamp to keep it. In our UUIDv7 library test, Python's standard library ran 60 minutes ahead of the clock after it stepped back an hour, because it chose order over honest time. A UUIDv7 or a Snowflake ID orders events on one machine well. Across machines, it orders them by whoever's clock is fastest.

Common misconceptions

What this means for you

If one database is your single writer, you do not need any of this; let it assign the order. If you run several writers, decide what you need to know. For "roughly in order, cheap", a Lamport clock or a time-ordered ID is fine. For "did these two writes conflict?", you need vectors or a hybrid clock, plus a merge rule. Either way, check your own servers' clock offset today; ours took 30 seconds to measure. Generate and decode time-ordered IDs in the browser with our UUIDv7 tool and Snowflake ID decoder.

Related

• Pick a UUIDv7 library that keeps order: 10 tested: the parent test, including the one-hour clock step.
• UUIDv7 vs UUIDv4 and UUIDv7 vs ULID.
• Snowflake ID vs UUID: time plus machine plus sequence in 64 bits.
• Build a database in Rust: where ordering bugs turn into failed tests.

FAQ

What is the difference between a Lamport clock and a vector clock?

A Lamport clock is one counter per process. It guarantees that if event a caused event b, a gets a smaller number, but a smaller number does not prove a caused b. A vector clock keeps one counter per process, so comparing two vectors tells you exactly whether one event happened before the other or whether they were concurrent.

Can a Lamport clock detect concurrent events?

No. Two events with Lamport times 2 and 3 might be cause and effect, or might have happened on different machines with no contact at all. In our simulation, Lamport clocks still put a strict order on 95.5% to 98.1% of the pairs that were actually concurrent.

Why not just use the wall clock?

Because machine clocks disagree. Our own Windows PC was 1,010 to 1,014 ms behind five public time servers on October 25, 2026, with its time service stopped. Any reply it sent within a second of receiving a message would carry an earlier wall-clock time than the message it answered.

What is a hybrid logical clock?

A hybrid logical clock, proposed by Kulkarni and colleagues in 2014, pairs the physical time with a small logical counter. It stays close to the wall clock but still respects cause and effect, and it fits in a 64-bit NTP-format timestamp. CockroachDB uses this approach and refuses to run when node clocks drift past 500 ms by default.

Why don't all databases use vector clocks?

They grow with the number of writers: one counter per node or client. At 8 bytes per entry, a 100-node vector is 800 bytes on every version, versus 8 bytes for a Lamport time. Amazon's Dynamo used them and reported that 99.94% of shopping cart reads saw a single version; Cassandra chose last-write-wins timestamps instead.

Sources

All checked October 25, 2026.

Papers

• Leslie Lamport, Time, Clocks, and the Ordering of Events in a Distributed System, Communications of the ACM 21(7), July 1978: the happened-before relation, the Clock Condition, the counter rules. Quotes on the paper from his publication list.
• Friedemann Mattern, Virtual Time and Global States of Distributed Systems: vector time.
• James C. Corbett et al., Spanner: Google's Globally-Distributed Database, OSDI 2012: TrueTime on GPS and atomic clocks, uncertainty about 1 to 7 ms (4 ms most of the time), commit wait of at least 2 times the uncertainty.
• Sandeep Kulkarni, Murat Demirbas et al., Logical Physical Clocks and Consistent Snapshots in Globally Distributed Databases, University at Buffalo tech report 2014-04: hybrid logical clocks, 64-bit NTP format.
• Giuseppe DeCandia et al., Dynamo: Amazon's Highly Available Key-value Store, SOSP 2007: vector clocks, 99.94% of requests saw one version over 24 hours.

Docs and standards

• Cockroach Labs, cockroach start: --max-offset, default 500ms, servers crash past it.
• Apache Cassandra, Dynamo architecture: last-write-wins instead of Dynamo's vector clocks.
• IETF, RFC 9562, sections 6.1 and 6.2: timestamp altering, monotonicity and counters.

Our data

• Simulation: 35 runs (2, 3, 5, 10, 20, 50 and 100 processes, 5 seeds each), 2,000 events per run, both clocks on every event, every pair compared, October 25, 2026. Every run is in data.csv on this page.
• Clock offset: 21 raw SNTP queries from our Windows 11 PC to time.google.com, time.cloudflare.com, time.windows.com, pool.ntp.org and time.nist.gov at 8:12 to 8:13 PM ET, cross-checked with w32tm /stripchart (about +1.01 s against all three servers it reached). w32tm /query reported the Windows Time service was not started.

Images

• Charts and diagram by Tensorust from the data above.