Engineering

Targeting 10,000 Ingests/Sec on PostgreSQL pgvector

An engineering target and the evidence we plan to publish for a reproducible pgvector ingest benchmark.

Aleksei Popov
Founder, MemHouse
July 28, 2026 4 min read

Status: This is an engineering target, not a released benchmark result. We will publish hardware, dataset, workload, configuration, raw results, and reproduction steps before making a measured throughput claim.

High-Concurrency Parallel Pipeline Architecture

When processing millions of continuous observations from thousands of autonomous agents, single-threaded pipeline architectures hit heavy bottlenecks in lock contention and async event loops.

By implementing MemHouse on a high-concurrency process architecture:

  • Each agent memory stream runs in isolated async execution tasks.
  • Fault isolation ensures that an error in one tenant’s memory extraction crash-guards without affecting other concurrent streams.
  • Supervisor connection pools handle database reconnects seamlessly.

Those properties describe the design direction, not measured throughput. Concurrency alone does not prove that PostgreSQL, pgvector, embedding generation, policy evaluation, and network I/O can sustain the target together.

What a Reproducible Result Must Include

A credible ingest benchmark needs enough detail for another engineer to run the same workload and challenge the result:

  1. Environment: CPU model and count, memory, storage, operating system, PostgreSQL and pgvector versions, and whether clients and the database share a host.
  2. Input: observation size distribution, embedding dimensions, tenant and scope cardinality, and the ratio of inserts to updates or rejected facts.
  3. Pipeline boundaries: whether the clock includes HTTP parsing, extraction, embedding generation, governance checks, and durable database commit.
  4. Database configuration: schema and indexes, connection-pool size, transaction batching, checkpoint settings, and the starting row count.
  5. Results: warm-up duration, sustained test duration, accepted and rejected operations, p50/p95/p99 latency, error rate, and raw time-series output.

The Experiment We Intend to Run

The target should be tested as a sustained workload rather than a short burst. Independent workers will submit observations across many account and scope pairs while the service records end-to-end latency and failures. The database must begin from a disclosed dataset size, and the run must include durable writes. A result that excludes extraction or embedding work must be labeled as a storage-only measurement.

We will report the highest repeatable rate that stays within declared latency and error thresholds, including unsuccessful runs and the first bottleneck observed. Until that evidence is published, 10,000 ingests per second remains a target, not a MemHouse performance claim.

Tags: Python PostgreSQL Performance Benchmarks

Related Articles & Release Notes

View All Posts →
Releases & Updates MemHouse Changelog

A concise index of releases documented on the MemHouse site, with roadmap items clearly separated from shipped interfaces.

2 min read Read
Comparisons MemHouse vs. Mem0: Architectural Differences in Agent Memory Governance

A focused comparison of MemHouse and Mem0 approaches to governance, fact lifecycle state, and tenant scoping.

3 min read Read
Tutorials Building a Compliant Customer Support Copilot in 10 Minutes

Step-by-step guide to integrating MemHouse with LangGraph and Claude to create support bots that remember customer preferences while adhering to strict privacy scoping.

5 min read Read