# Locality, and Temporal-Spatial Hypothesis

DevFeed: [Locality, and Temporal-Spatial Hypothesis](<https://devfeed.tech/articles/locality-and-temporal-spatial-hypothesis-12578.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2025/10/05/locality.html>)

Author: Marc Brooker

Published: 2025-10-05T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [Databases](<https://devfeed.tech/topics/databases.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [systems](<https://devfeed.tech/topics/systems.md>), [IO](<https://devfeed.tech/topics/io.md>), [Streaming](<https://devfeed.tech/topics/streaming.md>), [Time Series](<https://devfeed.tech/topics/time-series.md>), [observability](<https://devfeed.tech/topics/observability.md>)

Tags: [cache](<https://devfeed.tech/tags/cache.md>), [database](<https://devfeed.tech/tags/database.md>), [database-performance](<https://devfeed.tech/tags/database-performance.md>), [io](<https://devfeed.tech/tags/io.md>), [linux](<https://devfeed.tech/tags/linux.md>), [metrics](<https://devfeed.tech/tags/metrics.md>), [observability](<https://devfeed.tech/tags/observability.md>), [performance](<https://devfeed.tech/tags/performance.md>), [postgres](<https://devfeed.tech/tags/postgres.md>), [streaming](<https://devfeed.tech/tags/streaming.md>), [systems](<https://devfeed.tech/tags/systems.md>), [time-series](<https://devfeed.tech/tags/time-series.md>)

## AI overview

The article examines locality in database and computer-system performance, focusing on how temporal and spatial locality influence caching, read-ahead, and data layout. It develops the temporal-spatial locality hypothesis and compares its relevance for streaming, time-series, metrics, observability, and hash-based database systems.

## Source excerpt

Locality, and Temporal-Spatial Hypothesis Good fences make good neighbors? Last week at PGConf NYC, I had the pleasure of hearing Andres Freund talking about the great work he's been doing to bring async IO to Postgres 18. One particular result caught my eye: a large difference in performance between forward and reverse scans, seemingly driven by read ahead1. The short version is that IO layers (like Linux's) optimize performance by proactively pre-fetching data ahead of the current read point in a file, so it's already cached when needed. Notably, most of these systems don't do this backwards. This leads to a big difference in performance between forward scans (where the pages are already in the cache when they're needed) and backward scans (where the database needs to block on IO to fetch the next page). This lead me to thinking more about a particular hypothesis behind many database designs: a temporal-spatial locality hypothesis2. Before we get there, let's talk about locality more generally, because it might be the single most important idea in database performance (and computer systems performance generally). Temporal locality is the idea that data accessed recently is likely to be accessed again soon. This idea is what's behind CPU caches, database buffer pools, and most caches you'll come across in computer systems. Spatial locality is the idea that when we access data, we're likely to access nearby data soon. Almost all database systems take advantage of these forms of locality, and would lost significant performance without taking advantage of them. Stacks of books could be written about these ideas. Stacks of books have been written about these ideas. We could talk about cache-oblivious algorithms, or non-polluting read and write instructions, or have an argument about linked lists. Instead, I want to zoom in to a particular idea in databases: temporal-spatial hypothesis. The hypothesis I mean has a definition something like this: Temporal-spatial localit