This older article and its examples have not yet been reviewed against current APIs. Check the latest documentation before using the code or treating any example as a measured result.
A cache can help a slow catalogue, but first find out where the time goes. Inspect representative slow queries and their plans before adding another system to operate.
Inspect indexes and query counts
Start with the query plan. A composite or partial index may help if it matches the filters and ordering. Which index is useful depends on the data and workload.
Compare EXPLAIN ANALYZE results before and after the change.
Check list pages for N+1 queries: one query to get the list, followed by additional queries for individual items. Inspect the SQL and query count. Batching, selecting fewer fields, or using an aggregate may help. Do not assume every Prisma include produces the same pattern.
Check computed values and connections
For a calculation that is repeated on reads, consider a stored generated column. Check the expression, storage cost, write overhead, and query plan before adopting it.
Check connections under load, too. Pooling can reduce connection overhead, but its size and the deployment topology must fit your database limits.
Measure one change at a time and record the result. That makes it easier to tell which change helped.
-- before: seq scan on 1.4M rows
CREATE INDEX CONCURRENTLY idx_products_active_cat_price
ON products (category_id, price)
WHERE status = 'active';
-- generated column: read paths stop recomputing
ALTER TABLE products
ADD COLUMN net_price numeric(12,2)
GENERATED ALWAYS AS (price * (1 - discount)) STORED;
-- verify, don't assume
EXPLAIN (ANALYZE, BUFFERS)
SELECT id, name, net_price FROM products
WHERE category_id = 42 AND status = 'active'
ORDER BY price LIMIT 24;Measure one change at a time and record the result. That makes it easier to tell which change helped.