Identify CPU, memory, disk, and PostgreSQL version prerequisites before installing the ParadeDB extension.
ParadeDB runs on any x86-64 or ARM64 machine that can run PostgreSQL 15 or later. For proof-of-concept work, 2 vCPUs, 4 GB RAM, and 20 GB SSD suffice. Production search workloads start at 4 vCPUs, 16 GB RAM, and NVMe or performant cloud block storage.
ParadeDB targets PostgreSQL 15+. Earlier releases lack required extension APIs. Confirm the server version with SELECT version();
.Upgrade before proceeding if needed.
Allocate at least 2× the total size of vectors plus 20 % head-room for query work buffers. For an ecommerce catalog holding 5 M products (1536-dim vectors ≈ 30 GB), plan on 60-64 GB RAM.
Yes. ParadeDB performs random vector I/O during ANN search. Use local NVMe or provisioned IOPS cloud volumes. Aim for >50k IOPS and <1 ms latency.Magnetic disks bottleneck recall and latency.
Install GNU make, clang or gcc, and postgresql-server-dev-15
(Deb-based) or postgresql15-devel
(RPM). These provide headers for compiling the extension.
Run CREATE EXTENSION paradedb;
. Then execute:
SELECT paradedb_check();
The function raises NOTICEs if CPU SIMD support (AVX2/NEON), shared_buffers, or work_mem are below recommended thresholds.
Choose compute-optimized instances (AWS c7g, GCP c3) with local NVMe. Use managed Postgres wrappers only if they allow custom extensions.Otherwise run ParadeDB on self-managed Postgres in Kubernetes or on a VM.
Set:
shared_buffers = 25% of RAM
work_mem = 64MB
maintenance_work_mem = 2GB
max_parallel_workers = CPU cores
These values balance vector index build speed and query throughput.
.
Only if the provider lets you install custom C extensions. Amazon RDS & Cloud SQL do not; use Aurora Postgres Custom or self-host.
No. It leverages CPU SIMD (AVX2/NEON) for fast searches. GPU is optional and currently experimental.
Index size ≈ 1.1 × vector data size. For 30 GB embeddings, budget ~33 GB additional disk.