How Eden Builds Systems That Time Travel

At Eden, we built Eve: an open-source data gateway for routing live traffic to databases, LLMs, APIs, and the other backend systems modern applications depend on.

Eve sits in the network path between applications and infrastructure. That position matters: it lets teams route, secure, observe, govern, and migrate production traffic without rewriting application code.

The question is not whether gateways belong in the path. Modern systems need a shared control point for database routing, policy, observability, migrations, and AI governance.

The question is whether that control point is intelligent and fast enough to deserve the position.

Too many gateways stop at forwarding traffic and exporting counters. They can enforce policy, but they do not understand enough about the workload to remove work, shape concurrency, reuse expensive resources, or make decisions before traffic reaches the backend. They give teams control, but leave performance on the table.

A great gateway should be more than a checkpoint. It should be a place where the system gets smarter. It should understand protocol and request semantics well enough to route safely, enforce policy, preserve observability, and keep the hot path moving. The goal is not merely to minimize added latency. The goal is to give time back.

That is the premise behind Eden's data plane: build a gateway that can make connected systems feel like they time travel.

By time travel, we mean something concrete: when Eve Gateway is deployed in front of a database, the database path can get faster. The same application, the same backend, and the same workload can complete more work with less latency than the direct connection path.

Eve does not make the database faster by magic. It changes the shape of the work arriving at the database. It pools connections, multiplexes safe traffic, removes unnecessary protocol overhead, and shields the backend from client-side contention. To the application, the database behaves like it got time back.

The benchmark results are starting to show that this is not just a product story. In controlled head-to-head runs, Eden increased throughput and reduced latency relative to direct Postgres and PgDog, reduced proxy cost versus Envoy for Redis, and held OpenAI-compatible AI gateway load clean where Envoy's generic HTTP baseline collapsed.

The Short Version

The headline is not one benchmark number. It is the repeating pattern: when the gateway understands the workload, it can improve hot paths across very different protocols.

• On Postgres, Eden beat direct Postgres and PgDog on every 512-client workload in the suite, reaching up to 1.68x direct throughput on prepared reads.
• On matched Redis throughput, Eden completed the same 400k req/s workload as Envoy with lower p99 latency and about 32% less CPU per completed request.
• Under Redis overload, Eden sustained 2.3x Envoy's completed throughput with zero shed at the same offered rate.
• On OpenAI-compatible AI traffic, Eden handled 12k req/s / 6.36 Gb/s for buffered 64 KiB responses with zero errors, while the Envoy baseline collapsed at 8k offered.
• During live observability validation, Eve emitted a 185-metric catalog, stored 14,043 gateway metric rows, and captured 2,105 trace spans while load was running.

That is the part we care about most: not just faster in one lane, but faster while doing the production work a data and AI gateway actually has to do.

The Counterintuitive Goal

Saying that a gateway can be faster than connecting directly to a database sounds like it should be impossible. Direct should be the lower bound. Fewer hops should mean less latency.

That is true when the only thing a proxy does is forward bytes.

It stops being true once the bottleneck is not the extra hop, but the coordination around the backend. Applications often create too many connections, repeat protocol setup, serialize work that could be multiplexed, or make every client compete directly with the database scheduler. A protocol-aware gateway can change that shape.

Eden can pool backend connections, multiplex safe requests, pin sessions only when correctness requires it, route reads and writes differently, and keep the hot path allocation-light. The gateway becomes a coordination point. It absorbs the messy edge behavior from clients and presents the backend with a more efficient workload.

That is how a proxy can appear to time travel: it moves coordination earlier, closer to the request boundary, and avoids forcing the backend to rediscover the same facts over and over.

Postgres: Faster Than Direct, Faster Than PgDog

Our latest Postgres benchmark compared Eden against direct Postgres and PgDog on our 32-CPU Ubuntu Linux benchmark host. The run used pinned CPU groups for the proxy, Postgres, and load generator, 15-second pgbench phases, scale 10, and workloads covering simple reads, prepared reads, autocommit writes, inserts, and mixed read/write traffic. The suite completed 126 benchmark rows with zero failed rows.

At 512 clients, Eden was ahead of both direct Postgres and PgDog on every workload in the suite. The gap is largest on read-heavy workloads, but the write-heavy and mixed workloads also improved.

The mixed read/write row is intentionally less flashy. It is still a win, but it is a smaller one because correctness narrows the amount of work a gateway can safely reorder or multiplex. That is exactly the boundary we care about. Eden should take the fast path when the protocol and SQL shape make it safe, and return to the conservative path when query or session state gets complicated.

That safety rule matters. A database gateway cannot optimize by pretending SQL is simpler than it is. Transactions, session variables, temporary tables, prepared statements, advisory locks, COPY, LISTEN/NOTIFY, and other stateful features all affect whether a request can move independently. Eden's analyzer exists so the gateway can be aggressive when traffic is safe and exact when state matters.

This is the foundation for intelligent Postgres routing: not a pile of fragile special cases, but a protocol-aware decision engine that knows when time can be compressed and when it must be preserved exactly.

Redis: Lower CPU, Lower Tail Latency Than Envoy

The Redis results show the same philosophy on a different protocol.

Envoy is a very strong baseline. It is mature, widely deployed, and optimized for proxying. So our Redis benchmark was deliberately head-to-head: same host class, same workload shape, pinned services, and a load generator that precomputed RESP bytes and replayed them from memory.

At a matched 400k req/s mixed GET/SET load, Eden's Eve gateway completed the same work as Envoy with lower tail latency and substantially less CPU per request.

That is roughly 32% less CPU per request, with fewer cycles and fewer retired instructions per completed request, while Eden is doing protocol-aware work that a byte-forwarding proxy does not attempt.

The overload behavior is even more important. At a 400k offered open-loop load in the clean Redis matrix, Eden completed far more work and shed none of it.

Direct Redis in that row is a saturation signal, not a latency baseline. The useful point is that once the system was under pressure, Eden shaped the workload better. It sustained 2.3x Envoy's completed throughput with zero shed at the same offered rate.

On large 64 KiB Redis GET payloads, Eden also reached Envoy-class bandwidth while failing more cleanly. In the 4-vCPU single-backend run, Eden peaked at 14.0 Gb/s versus Envoy at 13.9 Gb/s. Eden recorded zero connection errors across the sweep; Envoy recorded connection errors in every peak phase. In the four-backend ring-hash run, Envoy reached 16.1 Gb/s and Eden reached 15.5 Gb/s, within roughly 3.5%, again with Eden recording zero errors versus Envoy's 11.

That balance is the thesis in miniature: raw speed matters, but graceful behavior under stress matters just as much.

AI Gateway: Higher Clean Ceiling Than Envoy

The same pattern is now showing up on OpenAI-compatible AI workloads.

These runs used Eve's AI gateway against a synthetic OpenAI-compatible backend and a generic Envoy HTTP proxy. The goal was not to benchmark model quality or provider behavior. It was to isolate the gateway path under buffered chat-style responses, streaming responses, and multi-agent/tool-shaped requests.

On large 64 KiB AI responses, Eve held clean throughput where the Envoy baseline collapsed under the offered load.

That is a different shape of result than the Redis benchmark, but it tells the same story. AI gateways are often treated as policy wrappers around HTTP. That is too small. Once model traffic includes routing, streaming, tools, fallback, policy, cost attribution, and audit, the gateway becomes part of the runtime.

A gateway that understands the request path can do more than forward HTTP. It can normalize requests, attach identity and policy context, preserve route and usage telemetry, and still keep the hot path fast.

The latency runs are just as important because real AI systems are not only single chat calls. They include agents, tool schemas, streaming, fallback, and governance logic. Eve sustained the full offered rate on the agent and streaming cases with low tail latency.

For small-response LLM traffic, recent fast-path work also let Eve hold a full 12k req/s at about 1.2 ms p99 with zero shedding.

The point is not that AI traffic is identical to database traffic. It is that the product requirement is converging. Teams need a gateway that can govern requests, attribute cost, enforce policy, expose telemetry, and keep latency under control while workloads move through models, tools, agents, and data systems.

Why The Gateway Can Win

The fastest gateway is not the one that does the least. It is the one that does the right work at the right time.

Eden's hot path is designed around a few principles.

First, parse once and make it count. The gateway should understand enough of the protocol to make routing and safety decisions without repeatedly materializing expensive intermediate objects.

Second, multiplex only when correctness allows it. For Postgres, safe autocommit reads and independent writes can use more of the backend in parallel. Stateful sessions stay pinned. Complex transactions stay conservative. Performance is not allowed to outrun semantics.

Third, remove avoidable scheduling noise. Connection reuse, prepared backend state, and controlled backend concurrency can be more efficient than letting hundreds of clients fight directly with the database.

Fourth, make observability part of the hot path. A gateway that gets faster only by turning off visibility is not a production answer. Eden's Redis benchmarks include runs with telemetry and request analysis enabled, and the normal hot path still held 384k req/s with zero shed. In a separate 30-minute validation window, Eve produced 185 metrics across gateway, LLM, IAM, endpoint, workload, migration, tool-safety, and analytics groups; stored per-command timing, parse breakdown, byte counter, bridge, pool, lane, and mirror data; and captured trace spans alongside structured logs. The AI gateway path is measured the same way: request normalization, route context, policy hooks, and usage accounting are part of the system we are optimizing, not decorations we add after the benchmark.

Finally, benchmark the thing until it tells the truth. A lot of performance work is not glamorous. It is pinning load generator cores away from proxy cores, checking whether the bottleneck is Postgres, the proxy, the kernel, Docker networking, or the harness, and rerunning the test after every optimization. The point is not to win one number. The point is to build a system whose performance model we can explain.

What We Mean By Time Travel

When we say Eden builds systems that time travel, the phrase is playful, but the mechanism is precise: Eve moves coordination work out of the backend's way.

You put Eve in front of the database, and the same database can answer more requests with less latency.

That is the opposite of how gateways are usually understood. Most teams expect a proxy to give them control and then hope the latency cost is small enough to ignore. Eden's goal is different: make the control point so intelligent and performant that it improves the data path.

The reason is workload shaping. Direct connections often force the database to spend time on connection churn, client-side contention, repeated protocol work, and traffic patterns that are safe but inefficient. Eve can handle some of that coordination once in the gateway, then present the backend with cleaner concurrency and fewer wasted cycles.

That is the time travel: Eden removes time the system used to waste before the request reached the real backend work. In the benchmark suite, that shows up as lower latency and higher throughput than direct Postgres on every 512-client workload we tested, lower tail latency and lower CPU per request than Envoy on the matched Redis run, and a higher clean ceiling than Envoy on large OpenAI-compatible AI responses.

Performance Is A Product Feature

A lot of infrastructure products treat performance as a benchmark slide at the end of the deck. We think it belongs at the center of the product.

If a gateway is going to sit in the critical path, it has to earn that position on every request. It has to make the system easier to operate, safer to migrate, richer to observe, and faster under load.

The recent Postgres, Redis, and AI gateway results are an important marker for us because they show the same pattern across very different protocols and workload shapes. Eden is not only matching specialist proxies. In these benchmark suites, it is beating direct database connections on throughput and latency, reducing proxy cost versus Envoy on Redis, and holding AI gateway load where the Envoy baseline collapses.

That is the bar we are setting for ourselves: the most performant gateway on the market, not by being the thinnest possible proxy, but by being the smartest possible place to put the hot path.

Benchmark Notes

These are controlled internal benchmark results on Adam, our Ubuntu 24.04 benchmark host. The Postgres suite used pgbench workloads at scale 10 with pinned CPU groups for the proxy, database, and load generator. The Redis suite used Cacophony with precomputed RESP payloads and matched workload shapes across targets. The AI gateway suite used synthetic OpenAI-compatible HTTP workloads against Eve, direct backend paths, and a generic Envoy HTTP proxy. Redis is the production-ready gateway protocol in this release; AI/LLM, agent, Postgres, Mongo, and other protocol surfaces should be read as development and evaluation data until those surfaces are explicitly promoted. Synthetic benchmarks are not a promise that every application workload will improve by the same amount, but they are the way we make critical-path overhead visible, then turn it into system leverage. The public benchmark brief has the current methodology, caveats, and reproduction paths: Eve performance benchmarks.

The next step is to keep broadening the suite: larger Postgres datasets, more realistic application query mixes, native-host runs beyond Docker networking, more write-heavy routing cases, and longer soak tests. The goal is not a single benchmark crown. The goal is a gateway whose performance advantage survives contact with real production traffic.

Start With The Open Source Gateway

Eden is open source under Apache 2.0. If you want to inspect the hot path, run the benchmark harnesses, or put Eve in front of your own Redis and AI gateway workloads, start here:

• github.com/eden-dev-inc/eden

Run it, profile it, break it, and compare it against the systems you already trust. The fastest way to understand Eden is to put it on a workload you already know, make the critical path visible, and measure what changes.