Benchmarks

This page reports several different tests. Read each result within its listed setup and workload. Local polling, raw SQS transport, the full PostgreSQL/SQS lane, and an AWS deployment each answer different questions. Performance can change with the workload, configuration, and software version.

PostgreSQL polling

These tests time prequeued tasks whose handlers do no work. The timer ends after Runlane saves the successful result. Durable observations were off, which is the default. Each task still kept its run and event history.

When tasks run at the same time, Runlane groups their storage work into bounded batches. This is why the rows with more concurrency use fewer SQL calls per task. At 1 × 1, there is no other work to share a batch.

PostgreSQL polling compared with pg-boss

The closest match used eight processes with 16 execution slots per process. In this local no-op test, Runlane reached 94.5% of the pg-boss harness's throughput.

Single-process results show a larger gap:

Runlane ran its full task lifecycle. The pg-boss test used public fetch({ batchSize: 1 }) and complete() loops from pg-boss 12.30.0. Runlane saves more lifecycle history. The test compares the overhead of both engines, but they do not store the same data.

At 8 × 16, Runlane made fewer SQL calls and used less PostgreSQL CPU. It also used about three times the worker CPU and wrote 15 times the WAL. Worker CPU and write volume were the largest measured gaps.

Local SQS transport

A separate test measured the built SQS adapter without the Runlane lifecycle or Postgres. It used Ministack on the same host.

The short consume runs used 2,000 messages. The longer runs used 10,000. The short rates fell when Ministack had to sustain the load, so they are burst results. All four-process runs completed without replay. Full native batches needed about 100 receive calls and 100 delete calls per 1,000 messages.

The publish result shows why batch fill matters: one ten-entry request carries ten messages instead of one. The FIFO result shows a different limit. One message group is serial by design, while independent groups can run at the same time.

These numbers show that the adapter uses SQS batching and ordering correctly. They do not predict AWS SQS throughput.

Local PostgreSQL with SQS

The full PostgreSQL/SQS lane was also tested with local Ministack. Ministack accepts the AWS SQS API, but it does not include AWS network latency, quotas, or service limits.

This test enabled a live observer and five durable observations per task. It used one process, 64 worker slots, and 1,000 prequeued no-op tasks. Unlike the polling test, its timer included worker startup and shutdown. The values below are medians of two runs. They describe the measured configuration, which differs from the default profile.

Runlane can receive and delete up to ten SQS messages in one request. This is why 1,000 tasks needed far fewer than 1,000 receive and delete requests. The receive count includes empty requests. Both measured runs completed every task once, with no transaction callback replays or SQL rollbacks.

Eager enqueue was measured on its own at 38.55 tasks/s and 14 SQL calls per task. This test used a live observer and one isolated trigger per task, so every publish contained one message. It did not measure concurrent publish batching. The SQL count is a measured result, not a fixed cost per enqueued task.

Local test environment

Each polling value is the median of two runs. The polling matrix completed all 52,000 measured tasks exactly once. It had no transaction callback replays, SQL rollbacks, or throttling.

These tests ran for tens of seconds on one shared host. They compare code paths under fixed conditions. They do not prove production capacity, latency, a service-level objective, an Aurora cost, or AWS SQS performance. SQL calls are not database I/O charges. WAL bytes are not Aurora billed I/O.

AWS deployment check

The AWS deployment used PostgreSQL 17 on db.t4g.micro, a maximum of 79 database connections, Lambda batch size 10, and one small Fargate worker. The cap-2 and cap-4 rows below were separate event-source settings; both used an application pool maximum of two. The load generator ran outside AWS. Producers, consumers, maintenance, and application queries shared the same database.

This setup reached deployment limits before the test found a Runlane or SQS limit. It does not prove that no later limit exists.

The Lambda workload read one application row with Prisma, waited 50 milliseconds to simulate an external provider, saved a durable step, and updated the row. It was not the no-op workload used in the local polling table.

The cap-2 rate is not a Runlane, Lambda, or SQS ceiling. It is the result of one small example deployment. A cap of two Lambda invocations can still run up to 20 records at once when both invocations receive full ten-record batches.

The failed uncapped run also had zero Lambda platform errors. The handler returned valid partial batch responses while some durable Runlane runs retried and later failed. Production checks must join AWS metrics with exact run states, attempts, retries, duplicates, and dead-letter queue state.

The Fargate result measures bounded admission. SQS was often empty while runs waited in Postgres for the next maintenance pass. It does not measure Fargate worker speed.

These checks do not establish sustained AWS capacity or cost per million tasks. A capacity test must measure these paths separately:

1. Ingress with consumers stopped.
2. Prequeued Lambda drain with producers stopped.
3. Prequeued long-running worker drain with producers stopped.
4. Continuous end-to-end traffic.
5. Bounded queue refill and recovery.

The load generator must run in the same AWS region and send work at a fixed rate. The database must have stable, non-burstable compute for a capacity claim. Each case must account for every accepted run. See Deploy with Postgres and SQS for sizing formulas.

Metric definitions

Small means the compact input used by the no-op benchmark. The 8 KiB case adds 8,192 bytes of deterministic text.

WAL measures database change volume. It is not the same as stored bytes or an Aurora I/O charge. SQL calls count client-server requests, which may contain work for many tasks when Runlane batches lifecycle changes.

Other adapters

Measure each storage and transport combination separately. Each system has different atomic operations, batch limits, network costs, and durability rules.

The storage and transport contracts remain the common boundary. Each adapter can use its native batch and atomic features while core keeps ownership of the task lifecycle. Every adapter needs its own single-process, multiprocess, payload, failure, and sustained-load results before making performance claims.