Why we built
CIUF

The simplest path to fast repeated queries shouldn't require running a second service, writing invalidation logic, or serialising your data twice.

The problem

Most Python applications hit the same PostgreSQL queries hundreds of times per second. The standard answer is Redis — a separate service you have to provision, monitor, serialise data into, and write invalidation logic for. That's a lot of infrastructure for what is, conceptually, a very simple problem: "don't recompute a result if the underlying data hasn't changed."

The alternative — manual in-memory dictionaries — works until your data has JOINs, GROUP BYs, or WHERE clauses. At that point you're maintaining a hand-written incremental view, which is exactly the kind of accidental complexity that causes on-call incidents at 3 am.

Our approach

CIUF takes a different angle: it parses your SQL query into a Directed Acyclic Graph (DAG) that mirrors the query's logical structure. Each node in the graph holds a materialized slice of the result. When a write happens — an insert, update, or delete — only the affected nodes are recomputed. Everything else is served directly from memory.

The result is sub-millisecond reads for any query that's been registered once, with automatic, correct invalidation. No Redis, no serialization round-trip, no hand-written cache keys.

Where we are

CIUF is in active development. The core engine — SQL parsing, DAG propagation, LRU/TTL eviction, and thread safety — is complete and tested. We're working toward a public v0.1.0 release on GitHub and PyPI. The library is MIT-licensed and will remain free and open source.

Values

🔬
Correctness first
A cache that silently returns stale data is worse than no cache. Every CIUF release passes a full incremental-correctness test suite before ship.
Zero overhead
In-process means no network hop, no serialization, and no external service to monitor. The fastest byte is the one you never send.
🔓
Open by default
MIT license, no feature gates, no usage limits. Commercial tiers exist for support — not to restrict what you can build.
🧩
Fits your stack
Works with raw psycopg2, SQLAlchemy ORM, and FastAPI. No ORM lock-in, no framework rewrites required.

Get in touch

Questions or feedback? Email us at hello@ciuf.io or open a GitHub Discussion.