Java vs Rust Benchmark — 10M Transactions

This page compares Spring Batch (Java 25 / Spring Boot 4.x) and Spring Batch RS (Rust) on a realistic ETL pipeline: reading 10 million financial transactions from CSV, storing them in PostgreSQL, exporting to XML, then re-importing from XML into a second PostgreSQL table.

Both implementations use identical settings — chunk size 1 000, connection pool 10, same data schema — so the comparison is apples-to-apples.

---

Test Environment

Parameter	Value
Machine	Apple Silicon, macOS
PostgreSQL	17-alpine (Docker container, same machine)
Java	OpenJDK 25, Spring Boot 4.0.4, Spring Batch 6.0.3
JVM flags	-Xms4g -Xmx4g -XX:+UseG1GC -XX:+AlwaysPreTouch
Virtual threads	Enabled (spring.threads.virtual.enabled=true)
Java XML	StAX (XMLStreamWriter / XMLStreamReader) — no JAXB
Rust	stable, --release + RUSTFLAGS="-C target-cpu=native"
Chunk size	1 000 (both)
Pool size	10 connections (both)
DB volume	Fresh Docker volume per run

Note

Results vary by hardware, PostgreSQL configuration, and disk speed. The numbers below are reference measurements — run the benchmark yourself to compare on your own infrastructure (see How to Reproduce).

---

Pipeline

Generate 10M rows → transactions.csv
        │
        ▼ CsvItemReader / FlatFileItemReader
  TransactionProcessor
  (USD/GBP → EUR conversion, CANCELLED → FAILED)
        │
        ▼ PostgresItemWriter / JdbcBatchItemWriter  (bulk insert, chunk=1000)
   PostgreSQL: table transactions
        │
        ▼ RdbcItemReader / JdbcPagingItemReader  (paginated, page_size=1000)
        │
        ▼ XmlItemWriter / XMLStreamWriter
  transactions_export.xml
        │
        ▼ XmlItemReader / XMLStreamReader  (chunk=1000)
        │
        ▼ PostgresItemWriter / JdbcBatchItemWriter  (bulk insert, chunk=1000)
   PostgreSQL: table transactions_import

Total wall-clock time includes CSV generation.

Transaction record

Field	Type	Example
transaction_id	string	TXN-0000000001
amount	float	1234.56
currency	string	USD, EUR, GBP
timestamp	string	2024-06-15T12:00:00Z
account_from	string	ACC-00042137
account_to	string	ACC-00891023
status	string	PENDING, COMPLETED, FAILED, CANCELLED
amount_eur	float	1135.80 (added by processor)

---

Code Side by Side

Step 2 — PostgreSQL → XML

Rust

// Keyset pagination: WHERE transaction_id > :last ORDER BY transaction_id LIMIT 1000
// O(log n) per page — avoids the O(n²) cost of LIMIT/OFFSET on 10M rows.
let reader = RdbcItemReaderBuilder::<Transaction>::new()
    .postgres(pool.clone())
    .query(
        "SELECT transaction_id, amount, currency, timestamp, \
         account_from, account_to, status, amount_eur \
         FROM transactions",
    )
    .with_page_size(1_000)
    .with_keyset("transaction_id", |t: &Transaction| t.transaction_id.clone())
    .build_postgres();

let writer = XmlItemWriterBuilder::<Transaction>::new()
    .root_tag("transactions")
    .item_tag("transaction")
    .from_path(xml_path)?;

Java

// JdbcPagingItemReader uses keyset-based pagination via sortKeys
@Bean
public JdbcPagingItemReader<Transaction> postgresReader(DataSource ds) {
    return new JdbcPagingItemReaderBuilder<Transaction>()
        .name("postgresTransactionReader")
        .dataSource(ds)
        .selectClause("SELECT transaction_id,amount,currency,timestamp," +
                      "account_from,account_to,status,amount_eur")
        .fromClause("FROM transactions")
        .sortKeys(Map.of("transaction_id", Order.ASCENDING))
        .rowMapper(/* maps columns → Transaction */)
        .pageSize(1_000).build();
}

// StAX writer — no JAXB reflection
@Bean
public TransactionXmlWriter xmlWriter() {
    return new TransactionXmlWriter(xmlPath); // wraps XMLStreamWriter
}

Step 3 — XML → PostgreSQL (transactions_import)

Rust

let reader = XmlItemReaderBuilder::<Transaction>::new()
    .tag("transaction")
    .from_path(xml_path)?;

let writer = RdbcItemWriterBuilder::<Transaction>::new()
    .postgres(pool)
    .table("transactions_import")
    .column("transaction_id", |t: &Transaction| t.transaction_id.clone().into())
    .column("amount", |t: &Transaction| t.amount.into())
    .column("currency", |t: &Transaction| t.currency.clone().into())
    .column("timestamp", |t: &Transaction| t.timestamp.clone().into())
    .column("account_from", |t: &Transaction| t.account_from.clone().into())
    .column("account_to", |t: &Transaction| t.account_to.clone().into())
    .column("status", |t: &Transaction| t.status.clone().into())
    .column("amount_eur", |t: &Transaction| t.amount_eur.into())
    .build_postgres();

Java

// StAX reader — no JAXB reflection
@Bean
public TransactionXmlReader xmlReader() {
    return new TransactionXmlReader(xmlPath); // wraps XMLStreamReader
}

@Bean
public JdbcBatchItemWriter<Transaction> importWriter(DataSource ds) {
    return new JdbcBatchItemWriterBuilder<Transaction>()
        .dataSource(ds)
        .sql("INSERT INTO transactions_import (...) VALUES (:transactionId, ...)")
        .beanMapped().build();
}

---

Results

Measured on the reference environment described above. Run on a fresh Docker volume each time. Total wall-clock time includes CSV generation.

Overall performance

Metric	Spring Batch RS (Rust)	Spring Batch (Java)	Rust advantage
Total pipeline time	114.1 s	199.7 s	1.75× faster
Generate CSV	1.8 s	6.7 s	3.7×
Step 1 — CSV → PostgreSQL	38.6 s	83.4 s	2.2×
Step 2 — PostgreSQL → XML	20.8 s	32.5 s	1.6×
Step 3 — XML → PostgreSQL	53.0 s	77.1 s	1.5×

Throughput (records/sec)

Step	Rust	Java	Ratio
Step 1 — CSV → PostgreSQL	259 095	119 964	2.2×
Step 2 — PostgreSQL → XML	481 773	307 560	1.6×
Step 3 — XML → PostgreSQL	188 594	129 671	1.5×
Average (full pipeline)	87 610	50 071	1.75×

Tip

The JAXB → StAX migration in Java Step 2 is the most dramatic finding. The previous benchmark used StaxEventItemWriter + Jaxb2Marshaller (reflection-based), which produced only 37 182 rec/s. Replacing it with direct XMLStreamWriter yields 307 560 rec/s — 8× faster — closing the gap with Rust from 13.2× down to just 1.6×.

The lesson: Rust’s advantage in XML serialisation is not an inherent JVM limitation — it is specifically JAXB’s per-record reflection overhead. Both runtimes are competitive when using streaming byte-level APIs.

---

Analysis

Why is Rust ~1.75× faster overall?

1. CSV generation (3.7× gap). Rust’s generator uses a simple linear-congruential RNG and writes directly to a BufWriter<File>. Java’s DataGenerator does the same, but JVM startup, JIT warm-up, and UTF-16 string handling add measurable overhead on a 10M-row write.

2. CSV → PostgreSQL (Step 1 — 2.2× gap). Rust uses zero-copy CSV parsing (no intermediate string allocation per field) and a single sqlx bulk-insert query per chunk. Java’s FlatFileItemReader allocates a String[] and a Transaction bean per row via bean-wrapper reflection.

3. PostgreSQL → XML (Step 2 — 1.6× gap). Both now use streaming byte-level XML APIs (no reflection). Rust’s advantage comes from lower memory pressure (no GC, no JVM metadata overhead) and tighter CPU cache usage across a 10M-row write.

4. XML → PostgreSQL (Step 3 — 1.5× gap). Both use StAX pull-parsing. Rust’s advantage is again GC-free memory and the absence of Spring AOP / transaction proxies on the write path.

5. No garbage collection. Rust uses RAII — memory is freed the instant a chunk goes out of scope, with zero pauses. Java’s G1GC introduces stop-the-world pauses that accumulate over a 10M-record run.

6. Keyset pagination (both Step 2 and Step 3). Spring Batch RS uses WHERE cursor_col > :last ORDER BY cursor_col LIMIT n — O(log n) per page. Java’s JdbcPagingItemReader with sortKeys uses the same strategy.

The JAXB lesson

The previous iteration of this benchmark showed a 13.2× gap on Step 2 (XML export). That gap was not a Java vs Rust problem — it was entirely due to JAXB’s reflection-based marshalling. Switching to XMLStreamWriter brought Java to within 1.6× of Rust on that step.

If you are running Java batch jobs with JAXB-based XML output, switching to StAX is likely the highest-ROI optimisation available.

When to choose Java

• Your team is Java-first and migration cost outweighs performance gains
• You need Spring ecosystem integrations (Spring Data, Spring Cloud Task, Spring Integration)
• Your batch jobs run infrequently and throughput is not the bottleneck
• You require rich operational features: JobRepository, JobExplorer, REST API control

When to choose Rust

• Throughput and latency are business requirements (financial settlement, real-time ETL)
• Memory is constrained (embedded systems, small containers)
• GC pauses would cause SLA violations
• You want a single statically-linked binary with no runtime dependency
• Cold-start time matters (serverless, frequent scheduling)

---

How to Reproduce

Prerequisites

# Start PostgreSQL with Docker Compose (from sbrs-java-bench/)
cd sbrs-java-bench
docker compose up -d

# For reproducible results, restart with a fresh volume between runs:
docker compose down -v && docker compose up -d

Run the Rust benchmark

cd sbrs-lib

RUSTFLAGS="-C target-cpu=native" \
cargo run --release --example benchmark_csv_postgres_xml \
  --features csv,xml,rdbc-postgres

Run the Java benchmark

cd sbrs-java-bench

# Build fat JAR once
mvn package -q -DskipTests

# Run
java -Xms4g -Xmx4g -XX:+UseG1GC -XX:+AlwaysPreTouch \
  -jar target/spring-batch-benchmark-1.0.0.jar

Note

Both benchmarks automatically truncate transactions and transactions_import before each run. Both generate their own CSV data — no shared input file is needed. Total wall-clock time printed at the end includes CSV generation.