Skip to main content

Test Environment

  • Hardware: Apple M-series (Rosetta 2 emulation for PostgreSQL)
  • PostgreSQL: 17.x with pgvector 0.8.x
  • Embedding dimensions: 1536 (text-embedding-3-small)
  • Note: All timings include Rosetta overhead. Native ARM builds are estimated 30-40% faster.

HNSW Vector Search Performance

Semantic recall latency using HNSW index (m=16, ef_construction=128, ef_search=64):

Native ARM Estimates

IVFFlat vs HNSW Comparison

Tested at 100K memories with top_k=10: Decision: HNSW chosen for production. The higher recall and no-retrain property outweigh the larger index size and slower initial build.

Audit Log Performance

Append-only audit table with BRIN index on created_at: Insert latency remains constant due to append-only writes. BRIN indexing keeps range scans efficient even at 10M+ rows.

Store Operation (End-to-End)

Full store including embedding generation, DB insert, and graph edge creation: Embedding generation dominates. With local embeddings (e.g., ONNX), total drops to ~5 ms.

Test Suite Results

Phase 1 + Phase 2 combined test run:

Rosetta Overhead Note

All benchmarks were collected on Apple Silicon under Rosetta 2 emulation (x86_64 PostgreSQL binary). Based on comparison testing:
  • CPU-bound operations (embedding similarity computation): ~35% overhead
  • I/O-bound operations (disk reads, network): ~5-10% overhead
  • Mixed workloads (typical Z3rno queries): ~20-30% overhead
Production deployments on native x86_64 or native ARM PostgreSQL builds should see proportionally better numbers. The benchmarks above represent conservative worst-case estimates.