A row cache
inside PostgreSQL.

Read rows by primary key with SQL mget or RESP. PostgreSQL writes automatically invalidate affected cache entries.

Explicit SQL API · PostgreSQL 14–18 · Open source

Measured locally · 15 Sep 2026

839,678requests/s · RESP MGET

3.31× the prepared SQL throughput
in this single-key comparison

Prepared SQL: 253,790 req/s
SQL mget: 186,296 req/s

Apple M3 Max · PostgreSQL 16 · Go · 256 connections.
Warm cache, 1 key/request. Median of 3 × 5 seconds.
SQL mget was slower here; batch results differ.

Results, raw data & conditions

One call. Two read paths.

An eligible hit returns the stored row. A miss or bypass reads the source table. Your ordinary SELECT queries keep their existing path.

psql │ primary-key reads

-- Attach your table once.
SELECT local_cache.attach_table('public.items');

-- Read rows by primary key.
SELECT local_cache.mget(
  'public.items', ARRAY[42, 7]::bigint[]
);

Node.js example Go example RESP example

{% include diagrams/read-path.html id="home-read" %}

What a row-cache hit avoids

SQL mget

Up to 1,024 keys per call. Order, duplicates, and NULL positions are preserved.

Ordinary writes

INSERT, UPDATE, and DELETE invalidate affected entries.

Fixed capacity

Allocate the shared row cache at PostgreSQL startup.

Snapshot checks

Ineligible reads use the source table under PostgreSQL visibility rules.

Run the same test.
On every client.

Node.js and Go. Prepared SQL, SQL mget, and RESP MGET.

One runner uses the same keys, batch sizes, connection counts, duration, and result checks. Compare throughput, latency, and PostgreSQL CPU and memory on your machine.

Run the comparison

Is this your workload?

Choosing a cache? Compare PostgreSQL pages, rows, materialized views, and Redis.

Worth measuring

Repeated complete primary-key lookups.
A small hot set of whole rows.
READ COMMITTED on one writable primary.
An application that can call the explicit SQL API.

Keep ordinary SQL

Joins, ranges, aggregates, or arbitrary query results.
RLS, partitioned, or inherited tables.
A database where you cannot install a native extension.
Workloads without a measured benefit.

Run a local demo.

Clone the repository and start a disposable PostgreSQL server with sample rows. Docker builds the extension and keeps the demo separate from your databases.

Git and Docker Compose required

git clone https://github.com/profundium/pg_local_cache.git
cd pg_local_cache
docker compose -f examples/compose.yaml up --build --wait

Read sample rows and check cache hits. Already cloned the repository? Run the last command from its root. For an existing server, use the installation guide.

Installing on an existing server requires a PostgreSQL restart.

Documentation

{% for item in site.data.navigation %} {{ item.title }}{{ item.description }} {% endfor %}

Before you try it

Does this replace shared_buffers?

No. PostgreSQL caches database pages. This extension separately caches serialized whole rows by primary key. See the read-path comparison.

Does it cache ordinary SELECT queries?

No. Only explicit local_cache.mget calls use the SQL cache. Your existing queries keep PostgreSQL's normal execution path.

Does it replace Redis?

No. The optional RESP2 endpoint is limited. There is no general-purpose Redis command set, TTL, pub/sub, or distributed coordination. Compare the PostgreSQL and Redis cache-aside paths.

How do I check updates and rollback?

The invalidation guide includes a two-session test. The runnable example checks uncommitted writes, read-your-writes, rollback, and committed updates.

A row cacheinside PostgreSQL.