Skip to main content

Client-side query caching for PyMongo

PyPI Python Coverage Typing

client-query-cache uses MongoDB change streams to asynchronously invalidate cached query results. It supports synchronous and asyncio applications without requiring a separate cache server.

%%{init: {"flowchart": {"diagramPadding": 75}}}%%
flowchart LR
    App["Python<br/>application"] -->|"Reads"| Cache["Client-side<br/>caching"]
    Cache -->|"Miss / bypass"| DB[("MongoDB")]
    DB -.->|"Change streams<br/>Async invalidation"| Cache

Cache hits are served from client-side memory, reducing read latency and database load in read-heavy applications.

The library is tested against real MongoDB replica sets, including concurrency stress tests, and automated checks guard its performance and memory use against regressions.

Illustrative read latency on a logarithmic scale: direct local MongoDB read, 120 microseconds; direct Atlas M0 read, 79.4 milliseconds; cached read in either deployment, about 61 microseconds.

Results vary by workload and deployment. Measurements and methodology.

Caching requires MongoDB 8.0+ on a replica set or sharded cluster. Reads on standalone servers and older MongoDB versions run through PyMongo without caching.

Invalidation is asynchronous: a cached read can return a preceding value until the write's change-stream event is processed. Use PyMongo directly when a read must immediately observe a preceding write; see consistency.

Eligible cache misses read from the primary with majority read concern, even when the collection leaves read concern unspecified, so only majority-committed results enter the cache. Uncached PyMongo reads use the deployment's default read concern, normally local. The two usually perform alike, but while replication lags or data-bearing members are unavailable, a miss can return older data or fail where an uncached read would not. Majority admission does not make cache hits current: invalidation remains asynchronous. See bypass conditions.

Quick start

uv add client-query-cache

Or use pip install client-query-cache.

from pymongo import MongoClient

from client_query_cache import CacheManager

with (
    MongoClient("mongodb://localhost:27017") as client,
    CacheManager(client) as cache_manager,
):
    collection = client["client_query_cache_tutorial"]["items"]
    cached_collection = cache_manager.get_cached_collection(collection)
    collection.replace_one(
        {"_id": "example"}, {"_id": "example", "value": 42}, upsert=True
    )
    cached_collection.find_one({"_id": "example"})  # Reads from MongoDB.
    cached_collection.find_one({"_id": "example"})  # Repeated reads can use the cache.

Shared application workers

For several trusted workers on one Linux x86-64 host, SharedCacheServer and sync/async SharedCacheManager share cached find_one() reads by _id and database change streams. Start the server in the application parent and attach each worker's own PyMongo client. Other reads use PyMongo. See the shared-cache deployment guide for the supported platform and lifecycle.

References

Getting started · Benchmarks · Examples


MongoDB is a registered trademark of MongoDB, Inc. This project is independent and is not affiliated with or endorsed by MongoDB, Inc.

Metadata

Release files for client-query-cache 0.8.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Built distribution (wheel)

Table of built distributions (wheels) for client-query-cache 0.8.0
File Interpreter ABI Platform
client_query_cache-0.8.0-cp314-abi3-manylinux_2_28_x86_64.whl CPython 3.14 abi3 Linux glibc 2.28+ x86-64 Details

Release files / client_query_cache-0.8.0-cp314-abi3-manylinux_2_28_x86_64.whl

Download URL client_query_cache-0.8.0-cp314-abi3-manylinux_2_28_x86_64.whl
Size 393.9 kB
Tags CPython 3.14 Linux glibc 2.28+ x86-64 abi3
SHA-256 checksum
How to use checksums
4ce06a2d60131a5fb74e6e6636d7374138bc5f23b9c44c1f3bf42e92958eb316
BLAKE2b-256 checksum
How to use checksums
53e755622877b1783d9c4619eeec19d1863c162aa31a0b167d718198c35cbae7
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 15, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.8.0 This release

1 release file

0.7.0

2 release files

0.6.0

2 release files

0.5.0

2 release files

0.4.0

2 release files

0.3.0

2 release files

0.2.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page