At 10, 50, and 100 concurrent sessions, agent workloads expose latency behavior that standard database benchmarks miss. Most latency tests target simple key-value throughput or analytical queries. An agent instead performs dependent reads and writes, with high, bursty concurrency and many small fetches rather than large scans. Each operation depends on the prior result, so the benchmark must model that sequence.
This post explains how we evaluate query latency in LaserData for agent access patterns and compares four approaches. We do not publish specific competitor figures. We are sharing a transferable method: when assessing an agent backend, test this workload structure rather than relying on sysbench or pgbench defaults.
Why standard benchmarks mislead
TPC-C represents transaction processing through order-entry mix ratios, while TPC-H represents analytical queries. pgbench models a simplified banking application. These tests remain useful because each enables repeatable, apples-to-apples comparisons within its intended workload class.
Agent workloads violate several assumptions in these tests. The read-to-write mix differs: TPC-C is roughly 4:1, while agent context workloads are nearer 3:1 or 2:1. Agent writes also commit reasoning steps that the next read must see immediately. Access is clustered around active session IDs and the recency window, not randomly distributed across a large key space. Concurrency is session-based: many sessions serialize their own operations while competing heavily for shared state objects.
Reporting "Xk queries per second" from a standard benchmark reveals little about behavior under an agent workload. The test must reflect the actual access pattern.
The four approaches we benchmark
Our internal suite regularly tests four architectural approaches. We are not creating a universal ranking. We are examining performance on agent-specific access patterns and the tradeoffs that appear as concurrency changes.
Approach A: Hosted relational database, connection pooled. A Postgres-compatible hosted database sits behind a transaction-mode connection pooler. This is a common starting point for agent backends, supported by mature query optimizers and client libraries.
Approach B: Key-value store with in-process read cache. A Redis-compatible store holds hot state, while the agent runtime keeps an in-process LRU cache. Writes pass through to Redis and reads check the local cache first. Teams often add this layer after finding the relational path too slow, without making it the primary store.
Approach C: Document store with secondary indexes. A hosted document database uses secondary indexes for session ID and timestamp. Reads go through those indexes, while writes use single-document upserts. This avoids Approach A's schema rigidity while retaining structured queries.
Approach D: LaserData. Our agent data backend uses pre-compiled access paths, persistent session connections, strong within-session consistency, and a binary wire format.
Benchmark workload definition
We simulate a multi-step research agent. Each session executes N steps, typically N = 10 and N = 50, so we can see latency accumulate with depth. Every step contains:
- A context read: fetch the current session state by session ID (point lookup, primary key).
- A derived read: fetch up to 5 most recent action records for the session (bounded range scan, sorted by timestamp descending).
- A write: append a new action record with updated state.
- A visibility check: confirm the write is visible to a sibling reader (simulating a coordinator agent checking sub-agent progress).
We test 10, 50, and 100 simultaneous sessions. For every configuration, we record per-step p50, p95, and p99 latency at the SDK layer, using wall-clock time from query issuance to the result arriving in application code. Each run lasts 60 seconds after a 10-second warmup.
Step 4's visibility check is the clearest separator. It captures write-read latency under concurrency, where systems using async replication tend to show their weakest behavior.
What we observe, and why
We are not citing exact figures because meaningful comparison would require third-party verification. Instead, this is the qualitative pattern we repeatedly see across configurations and expect a comparable benchmark to reproduce:
At 10 concurrent sessions, all four approaches deliver acceptable p50 latency for most agent systems, which explains why backends often look fine in development. p99 differences already exist, but the absolute values are small. Approach B has the strongest p50 through in-process read-cache hits, while its write path adds latency across the step sequence.
At 50 concurrent sessions, the gap widens. Approach A shows connection-pool saturation: with each session issuing 3-4 rapid operations per step, queue depth creates jitter and p99 spikes. Approach B's local cache becomes a problem when one session's writes must reach a sibling session, because that reader's process has not been invalidated. Teams usually see this when coordinator agents read stale sub-agent state.
At 100 concurrent sessions, the approaches separate most clearly. Approach C can outperform Approach A because document upserts avoid row-level lock contention, but its timestamp index slows under frequent writes as maintenance becomes a bottleneck. Approach D, LaserData, shows the smallest p99 increase relative to p50 during the concurrency ramp. Pre-compiled execution paths remove optimizer overhead, while persistent connections remove reconnection jitter.
The step-depth effect
Per-step latency matters, but accumulated latency matters more. If a step averages Xms with Yms of variance, a 10-step agent takes roughly 10X plus the variance spread. A 50-step agent takes roughly 50X, with variance growing nonlinearly because slow steps create backpressure in the session queue.
That is why we test both N=10 and N=50. An approach with p50 that is 20% worse at N=10 can produce 50% more total wall-clock time at N=50 when variance accumulates differently. We have seen teams optimize single-step p50 while missing a step-50 p99 that is 3 to 5 times p50 on a 50-step task because they did not measure end-to-end session duration.
For a multi-step agent, use the 95th percentile of total session completion time across representative sessions at expected concurrency. Single-step p50 is a useful leading signal, but it is not enough.
How to run this yourself
To apply this method to your current backend, start with three required pieces:
Use a test driver for the four-operation sequence: context read, range read, write, and visibility check. Record latency per step at the SDK layer. Server-side execution time is insufficient because round-trip time includes serialization, transport, deserialization, and application-code overhead. Measure wall clock from call to result.
Populate realistic session history with a data generator. A cold-cache first read differs from a warm-cache read on a session active for 100 steps. The data set should match your expected session-depth distribution.
Test at expected production concurrency, not a fraction of it. A common mistake is using 10% of production concurrency because the run is only a benchmark. Concurrency is often the key variable: a backend that looks fine at 10 sessions may change behavior qualitatively at 100, which a 10-session test will miss.
We are happy to share our internal benchmark tooling with teams evaluating LaserData. The test driver is included in our early access developer resources. The important point is not the exact result, but measuring the right workload before choosing an architecture that becomes expensive to change in production.
Methodology honesty
Our internal benchmarks have clear limits. They measure LaserData on our infrastructure and other systems on their cloud-hosted configurations. Hardware SKUs, regional network latency, client library versions, and configuration tuning vary, and we do not control all of them. The results show how LaserData behaves on agent access patterns and reveal qualitative differences among approaches. They are not a replacement for testing your workload, infrastructure, and query patterns.
Run the four-step workload above against your current backend before switching. If its p99 fits your agent's planning-loop budget at expected production concurrency, you may not need to change it. We are not saying every team needs LaserData; we are saying your decision should rest on a concrete measurement of your workload, not a vendor marketing claim, including ours.