On-prem integration runtime resource usage: memory, CPU and disk, measured

A request we hear often from prospects is to move data from a database inside their network to a cloud warehouse, on a schedule, without opening that database to the internet. That means installing software inside the network: an agent or a runtime. Before anyone discusses the warehouse, IT and security teams ask what that software will cost their servers and what it can reach.

The usual answer is a page of minimum requirements. We wanted to answer with measured numbers, so we ran the On-Prem Worker through a week of tests, from small event flows to million-row loads, and recorded what it used. This post gives the numbers, the method and the limits.

This post answers the first question for a local runtime. What the runtime sends out of your network, and what happens when the internet drops, are covered in a separate post.

All tests used synthetic or test data, generated by us, on our own hardware, between October 2 and 8, 2026.

• Deployments: we ran the runtime two ways, as a background service and in a container capped at 4 CPU cores and 4 GB of RAM. The test machine also hosted the PostgreSQL, Valkey (an open-source, Redis-compatible cache) and Kafka instances it read from and wrote to, so the runtime competed for memory more than it would on a dedicated server.
• The workloads: 15 flows deployed to the runtime (events, files, CRM syncs and database loads); a 1 million row load from a local PostgreSQL database into a cloud database, with data-quality checks and masking; fuzzy duplicate matching over about 970,000 records; and, to isolate the effect of batch size, a plain copy from PostgreSQL to Valkey at 1,000 to 5 million rows.
• The tools: standard process tools sampled the runtime's memory and CPU every half second, and the container's own memory statistics separated process memory from file cache. Start and finish times came from the runtime's log, and the 15 flows' averages came from the Neblex console.

Your records, connectors and hardware will shape your own numbers; the patterns are what carry over.

Very little. The runtime is a single executable, about 74 MB on macOS and 92 MB on Linux x64.

It needs no separate language runtime, such as Java, .NET or Node.js, and it starts no child processes. Builds are published for Linux x64, macOS on Apple Silicon and Windows x64.

For a security reviewer, the small number matters less than what it implies: there is no separate runtime to patch and no helper processes to account for.

It depends on what the flow does. Memory follows how much the flow holds at once, CPU follows how much it computes per record, and run time follows the destination.

The sections below take each row in turn.

Most use about as much memory as the idle runtime. We deployed 15 different integrations to one On-Prem Worker, covering events, file transfers, CRM syncs, cache updates, database loads and an AI step, which gives a broad sample of how the runtime behaves. The Neblex console reports CPU and memory for each flow, averaged across its runs, on synthetic or test data. Run times come from the runtime's log, from start to finish of each successful run.

*A 1 million row load took 402 to 1,240 seconds, from 5,000 down to 100 rows per insert statement.

Fourteen of the 15 flows averaged 29 to 94 MB, close to the runtime's idle memory. Only the bulk load from local Postgres went above 100 MB. The event-driven flows, reading from MQTT, Kafka and AMQP, averaged 4 to 6% of one core. Twelve of the 15 finished in under 5 seconds on average; the AI tagging flow's 20 seconds is mostly spent waiting for the language model, with CPU under 2%.

Less than 450 MB at its peak. Moving data from a database inside the network to a cloud database is the request we hear most, so we ran it at full size: 1 million synthetic customer rows from a local PostgreSQL database into a Supabase table, which is hosted PostgreSQL, over a home internet line (about 175 Mbps down and 44 Mbps up).

Each row went through four data-quality checks, and its email was hashed and its phone number cut to the last four digits before it left the machine. Rows that failed stayed in a quarantine table on the local network. We repeated the load four times, with 100, 1,000, 5,000 and 10,000 rows per insert statement.

• The runtime's own memory peaked at 320 to 445 MB across the four runs and spent most of each run near its median of 53 to 118 MB.
• CPU averaged 12 to 26% of one core.
• Every run loaded exactly 976,000 rows and kept 24,000 in local quarantine. The fastest took 402 seconds.
• The internet line was never the limit: uploads averaged about 5 to 7 Mbps of the 44 available.

A later post covers the checks, the masking and how batch size changed the timing.

About one CPU core, and more memory. Comparing records with each other is a different kind of work from passing them through, so we ran fuzzy duplicate matching on the runtime: about 970,000 customer records, grouped by zip code, with names and streets scored for similarity inside each group. The candidate pairs stayed in a local table.

• First run, 970,000 records: 1,510 seconds. CPU averaged about 102% of one core, peaking at 217%, and resident memory peaked at 534 MB.
• Repeat with extra preparation, 976,000 records, on the same machine with the runtime running as a background service: 1,683 seconds. CPU averaged 93%, and resident memory peaked at 947 MB.

If you plan matching, scoring or heavy transformation on the runtime, size for this case rather than for the everyday flows.

In every bulk run, the runtime spent most of its time waiting for the destination, not computing.

• We built the Valkey flow to write one record per command and wait for each reply, so the local copy ran at roughly 7,500 to 9,400 rows per second. Raising the flow's concurrency setting to 4 and then 64 didn't change that rate. That fits what Valkey's documentation on pipelining describes: when a client sends one command at a time, round-trip time is the limit.
• Inserting into the cloud database one row per statement took about 0.35 seconds per round trip, under 3 rows per second. Grouping thousands of rows into each statement brought the full 1 million rows down to under 7 minutes.

Reading was far faster than writing, so millions of rows were waiting to be written at once. The runtime absorbed that gap: its memory stayed flat while the waiting rows sat in its local run journal on disk, covered below.

For large loads, batching writes is the lever, with any agent or runtime. The reassuring part for a server owner is the other side of the same finding: a runtime that is mostly waiting uses little CPU.

Memory grows with the batch the runtime holds at once; CPU stays low. To isolate batch size we used the plainest flow we had, a copy from PostgreSQL to a local Valkey cache.

*From a repeat 1 million row run on varied data (116.6 s), measured as the process's own memory including compressed pages.

The 1 million row run took 106 seconds, about 9,400 rows per second. The runtime held about 250 MB during the run and dropped to about 70 MB around 20 seconds after it finished. CPU averaged about 22% of one core at every size.

On disk. During a 5 million row batch, the runtime's own memory stayed flat at about 420 MB while it wrote the in-flight batch to its local run journal, about 1.7 GB or roughly 350 bytes per row.

The run journal is a durable local record of the batch that lets a run recover from an interruption. The runtime's logs describe it as hash-chained, sealed and flushed to disk.

The runtime purges it once the run is settled: after that run, its data folder went from about 1.7 GB back to about 1 MB. Neblex doesn't store your records; anything that must persist lives in your own database. Plan disk for the journal, roughly the size of the largest batch you expect to move.

It sizes itself to the deployment it runs in, rather than to a fixed setting. Installed as a service on a server it reads the machine's resources; in a container it reads the container's limits, not the host's.

• Memory sets how much work it accepts. At start, the runtime checks the memory available to it, including a container's limit, and sets how many jobs it will take on. The limit scaled with memory: on the larger test machine it allowed several times as many jobs as in the 4 GB container, and capped at 1 GB it accepted no work at first. CPU didn't change it.
• Disk holds what is in flight. It reserves disk for its run journal at start, from about 5 GB to about 25 GB depending on the deployment in our tests, and writes large in-flight batches there, so its memory stays flat while a slow destination catches up.
• The journal is emptied as runs settle, so the disk use is temporary.

For sizing, our tests ran comfortably within 4 CPU cores and 4 GB of RAM, and we treat that as the practical minimum for a production install. Add disk for the journal as described above. Published minimum requirements for the runtime are being finalized by our engineering team.

• Size for your heaviest flow, not the average. Everyday flows sit close to idle; matching, scoring and heavy transformation keep about one core busy and can approach 1 GB.
• Plan disk for the run journal, roughly the size of the largest batch you expect to move.
• Batch your writes. Throughput follows how the flow writes: one record per command waits on every round trip, while grouping rows per statement took a 1 million row load from an estimated four days to under seven minutes.
• Account for record size. Our test records were about 275 to 290 bytes; larger records raise memory, journal size and run time in proportion.
• Give it room. Capped at 1 GB, the runtime accepted no work at first; 4 CPU cores and 4 GB of RAM is a comfortable starting point.

Whatever on-prem integration agent you evaluate, measure its resource usage before and during a real job, and ask the vendor exactly what the agent sends out of your network.

• Neblex internal tests, October 2 to 8, 2026: synthetic data generated by Neblex, on Neblex hardware (a shared test machine, and a container capped at 4 CPU cores and 4 GB of RAM), with timings from the runtime's log and per-flow averages from the Neblex console.
• Valkey documentation: Pipelining
• Valkey documentation: Bulk loading
• Linux kernel documentation: Control Group v2, memory.stat
• ps(1) and footprint(1) manual pages.

Last checked: October 7, 2026.