paradedb.memory_usage() returns detailed shared-buffer and local memory statistics for all ParadeDB indexes in the current PostgreSQL database.
Memory-heavy vector indexes can slow queries and evict useful data from shared buffers. Frequent checks help you tune work_mem, shared_buffers, and autovacuum settings before problems appear.
The function lists each ParadeDB index, its size on disk, the portion cached in shared buffers, local work_mem consumed by the last operation, and the percent of total shared_buffers in use.
Run the function in any database where the ParadeDB extension is installed. Superuser rights are not required because the view is SECURITY DEFINER.
1. Connect to your analytics database.
2. Execute SELECT * FROM paradedb.memory_usage();
3. Review the shared_mb
and work_mem_mb
columns for spikes.
shared_mb > 75% of shared_buffers signals pressure; increase shared_buffers or drop rarely used indexes. work_mem_mb > current work_mem means sorts spilled to disk; raise work_mem or batch your queries.
Create indexes only on frequently searched embeddings. Use VACUUM (INDEX_CLEANUP)
after large deletions to reclaim space. Schedule REINDEX
during low-traffic windows to shrink bloat.
Creating huge HNSW indexes without raising shared_buffers leads to cache eviction. Forgetting to set maintenance_work_mem high enough slows bulk index builds.
See the FAQ below for quick answers on permissions, overhead, and automation.
No. The function is SECURITY DEFINER and executable by any user with USAGE on schema paradedb.
Run it daily in staging and production or hook it into pg_monitor dashboards for real-time alerts.
Yes. Combine the query with a cron job that triggers REINDEX or VACUUM when shared_mb crosses a threshold.