Sub-millisecond PostgreSQL queries.
Without Redis.

CIUF builds a DAG that mirrors your SQL query. Hot reads return from memory in <1ms. Writes propagate incrementally, with no full recomputation and no manual invalidation.

Numbers you can reproduce

Test setup: Python 3.11 · PostgreSQL 15 · 500k orders · 10k customers · 3-table JOIN. Measured on localhost to eliminate network variance.

Hot read latency drops by 15–250× vs Redis. Writes propagate incrementally — 1 row changed → 1 row recomputed, not a full cache flush.

Redis is the wrong tool
for SQL query caching

Redis is excellent for key-value access. For complex SQL results, it creates a maintenance burden that grows with your schema.

Three steps, no infrastructure.

CIUF mirrors your SQL query structure in memory as a DAG. Reads are pure in-memory lookups. Writes propagate only the changed delta.

from ciuf import Engine

engine = Engine(
    "postgresql://user:pass@localhost/mydb"
)

from ciuf import from_sql

result = from_sql(engine, """
  SELECT orders.id, orders.amount,
         customers.name
  FROM orders
  JOIN customers ON orders.customer_id
                  = customers.id
  WHERE customers.plan = 'pro'
""")
df = result.query()  # <1ms hot

# After inserting a new order
engine.on_insert("orders", {
    "id": 12345,
    "amount": 99.0,
    "customer_id": 42,
})

# After updating a customer
engine.on_update("customers",
    new={"id": 42, "plan": "pro"})

# Next read is <1ms, already up-to-date
df = result.query()

Built for read-heavy
Python services

Everything you need to cut query latency to under a millisecond — nothing you don't.

Drop-in, not a rewrite

CIUF sits alongside your existing database code. Add it to one endpoint, measure the difference.

from ciuf import Engine, from_sql

# 1. Connect (discovers schema automatically)
engine = Engine("postgresql://user:pass@localhost/mydb")

# 2. Register a cached query
result = from_sql(engine, """
    SELECT orders.id, orders.amount, customers.name, customers.plan
    FROM orders
    JOIN customers ON orders.customer_id = customers.id
    WHERE customers.plan = 'pro'
""")

# 3. First call hits the database; all subsequent calls are in-memory
df = result.query()
print(df.shape)  # (n_rows, 4)

# 4. Notify CIUF about writes
engine.on_insert("orders", {"id": 9001, "amount": 49.0, "customer_id": 42})
engine.on_update("customers", new={"id": 42, "plan": "pro", "name": "Acme"})
engine.on_delete("orders", {"id": 123})

# 5. Next read reflects changes, still <1ms
df = result.query()

from sqlalchemy import event
from sqlalchemy.orm import Session
from ciuf import Engine

ciuf_engine = Engine("postgresql://user:pass@localhost/mydb")

def _row_to_dict(obj):
    return {c.key: getattr(obj, c.key) for c in obj.__mapper__.column_attrs}

# Hook into SQLAlchemy session flush
@event.listens_for(Session, "after_flush")
def sync_ciuf_on_flush(session, flush_context):
    for obj in session.new:
        ciuf_engine.on_insert(obj.__tablename__, _row_to_dict(obj))
    for obj in session.dirty:
        ciuf_engine.on_update(obj.__tablename__, new=_row_to_dict(obj))
    for obj in session.deleted:
        ciuf_engine.on_delete(obj.__tablename__, _row_to_dict(obj))

# From this point on, every ORM write automatically updates the CIUF cache

from fastapi import FastAPI
from ciuf import Engine, from_sql

app = FastAPI()

# Initialize once at startup
ciuf_engine = Engine("postgresql://user:pass@localhost/mydb")

# Pre-register the query on startup
dashboard_result = from_sql(ciuf_engine, """
    SELECT orders.id, orders.amount, products.category
    FROM orders
    JOIN products ON orders.product_id = products.id
    WHERE orders.status = 'completed'
""")

@app.get("/dashboard")
async def get_dashboard():
    # Sub-millisecond from the second request onward
    df = dashboard_result.query()
    return df.to_dict(orient="records")

@app.post("/orders")
async def create_order(order: dict):
    # ... write to DB ...
    ciuf_engine.on_insert("orders", order)
    return order

CIUF vs Redis

CIUF and Redis solve different problems. Use this table to decide quickly.

In active development

The core engine is complete and tested. The public release is gated on the full M1–M4 milestone — when every component is production-ready, the repo goes public.

Star the repo to be notified when v0.1.0 ships. Questions? Open a GitHub Discussion.

Cut query latency to under a millisecond.

One command. Works with your existing SQLAlchemy setup, nothing else to run.