Join CSVs Bigger Than Your RAM With Constant Memory (10GB+ per side verified — up to 18.84GB output)
External sort-merge join — both files sorted to disk, never loaded into RAM. Memory stays flat at ~250–390MB no matter the size. 7 join types, composite keys, explosion detection — all in your browser with zero uploads. CSV Merger for full data preparation workflows, or see the full tool overview.
~250–390MB
Memory Footprint
constant, any file size
10GB+
Maximum Tested
per side (~22GB joined, 18.84GB out)
Never
File Uploads
zero transmission
7
Join Types
incl. Anti & Semi
Throughput by Output Mode
What these numbers measure: SplitForge times are compute benchmarks — from worker init to download prompt. Chrome (stable), Windows 11, dev machine (Alder Lake class), 64GB RAM, June 2026. Throughput is total input rows (left + right) per second. Results vary by hardware, browser, join type, and match rate (±15–20%).
Excel 900s is a workflow estimate, not a compute benchmark — it represents a typical end-to-end VLOOKUP workflow (write formula, drag down, IFERROR wrapper, copy-paste as values, troubleshoot mismatches) from internal testing, February 2026. Actual workflow time varies by user familiarity and file complexity. These are not directly comparable numbers — the intent is to show why the tool context matters, not raw compute speed.
Performance at Scale
Chrome (stable) · Windows 11 · dev machine (Alder Lake class) · 64GB RAM · June 2026 · throughput = total input rows (left + right) per second
Workload
Order-preserving (A)
Key-sorted (B)
Notes
1M input rows (moderate)
~109K rows/sec
~151K rows/sec
Small inputs run fast and are not disk-bound — highest per-row throughput
55M × 49.5M (~22GB in, 18.84GB out)
~69K rows/sec
~85K rows/sec
Standard inner join at 10GB+ per side; heap 255–391MB; zero spills
One-to-many 8× (48M output rows)
~47K rows/sec
~99K rows/sec
A restores left order with an extra sort that grows with output; heap ≤314MB
Pathological hot key (5M duplicates)
~71K rows/sec
~84K rows/sec
The oversized key group spills to disk; heap ≤350MB
Throughput is total input rows (left + right) per second, measured at the 10GB gate. Order-preserving (A) restores the left file's row order with an extra sort, so its overhead grows with output size; key-sorted (B) skips that step. Memory stays bounded at ~250–390MB across every workload. Results vary by hardware, match rate, and output column count.
Join Type Performance Overhead
Inner Join (Default)
Baseline
Baseline
Returns only rows with matches in both tables. Smallest output. Both files are sorted by join key to disk and merged in a single streaming pass; matches are emitted as the two sorted streams advance. Fastest join type because unmatched rows are skipped during the merge.
Left Join
+8% time
+~8% time
All left rows returned, matched or not. Unmatched left rows get empty values for right columns. Overhead: must write null-padded rows for non-matching left keys. This is the closest equivalent to Excel VLOOKUP — but returns ALL matches, not just the first.
Right Join
+15% time
+~15% time
All right rows returned, matched or not. Unmatched right rows are emitted during the same key-ordered merge pass, then the output is restored to right-file order. Slightly more overhead than left join.
Full Outer Join
+20% time
+~20% time
All rows from both tables, nulls where no match on either side. Combines left join logic with unmatched right rows. Largest possible output (sum of both tables minus inner join rows). Use with caution on large files — output can be much larger than either input.
Anti Join
<0% (faster)
Faster than inner
Left rows WITHOUT a match — no right columns assembled. Faster than inner join because output rows are simpler (left columns only, no right column assembly). Use to find orphaned records: customers without orders, products not in price lists, invoices without payments.
Semi Join
<0% (faster)
Fastest
Left rows WITH a match, but without right columns. Fastest of all join types: the merge confirms the match, the left row is written as-is, and right columns are never assembled. Use when you need the left table filtered by the right table but don't want right column data added.
Cross Join warning: Cross join generates a Cartesian product — every left row × every right row. 1,000 × 1,000 rows = 1,000,000 output rows. 5,000 × 5,000 = 25,000,000 rows. SplitForge hard-caps Cross join output at 100,000,000 rows. Pre-join analysis shows estimated output count before you commit. Always run analysis first for Cross joins.
Relative overhead figures are from moderate-scale testing (Chrome stable, 64GB RAM, dev machine (Alder Lake class)). Absolute throughput at 10GB+ scale is in the table below. Results vary by hardware, browser, match rate, and file complexity.
Calculate Your Time Savings
Manual baseline: ~15 minutes per join operation via Excel VLOOKUP — based on internal workflow testing, February 2026. This covers: write VLOOKUP formula, drag down all rows, wrap in IFERROR, copy-paste as values to remove formula dependency, troubleshoot mismatches and #N/A errors, repeat for each join column. SplitForge completes the equivalent join in under 60 seconds including the pre-analysis step, and returns all duplicate matches (not just the first).
Typical: 1–4 joins per data prep session
Weekly = 52, Monthly = 12, Daily = 260
Analyst avg: $45–75/hr
Annual Time Saved
25.1
hours per year
Annual Labor Savings
$1,257
per year (vs VLOOKUP workflow)
What you eliminate:
Writing and dragging VLOOKUP formulas across hundreds of thousands of rows
IFERROR wrappers and #N/A troubleshooting
Copy-paste as values to remove formula dependency before sharing
Missed duplicate matches that corrupt aggregations downstream
Excel crashes when joining files over 1,048,576 rows
Testing Methodology
10 runs per config · drop high/low · report avg + range · test datasets available on request
Expand
Honest Limitations: Where SplitForge VLOOKUP/Join Falls Short
No tool is perfect for every use case. Here's where Server-Side Join Tools (SQL Databases, Python pandas, AWS Glue) might be a better choice, and the real limitations of our browser-based architecture.
Browser-Based Processing
Performance depends on your device's RAM and CPU. Modern laptops (2022+) handle 10M+ rows easily, but older devices may struggle with very large files.
Workaround:
Close unnecessary browser tabs to free up memory. For files over 50M rows, consider database solutions.
No Offline Mode (Initial Load)
Requires internet connection to load the tool initially. Processing happens offline in your browser after loading.
Workaround:
Once loaded, you can disconnect and continue processing. For true offline environments, desktop tools may be better.
Browser Tab Memory Limits
Most browsers limit individual tabs to 2-4GB RAM. This is the practical ceiling for file size.
Workaround:
Use 64-bit browsers with sufficient RAM. Chrome and Firefox handle large files best.
Disk Space, Not Memory, Is the Ceiling
There is no in-memory hash table, so RAM is not the limit. Both files are sorted to disk (OPFS) and merge-joined in a single streaming pass, holding a constant ~250–390MB of heap whether you join 1 million rows or 10GB+ per side. The practical ceiling is free disk space — a join needs room for the sorted copies of both inputs plus the output. Verified at 10GB+ per side (≈22GB combined input, 18.84GB output).
Workaround:
If you run low on disk, free space or split the larger file into chunks, join each against the other file, then concatenate with CSV Merger. For recurring automated 50M+ row joins, a database SQL JOIN or Python pandas merge() may suit the pipeline better — for orchestration, not memory.
No Fuzzy or Approximate Matching
Keys must match exactly (or case-insensitively if toggled). No Levenshtein distance, phonetic matching, or pattern-based matching. 'Smith' and 'Smyth' will not match.
Workaround:
For fuzzy matching, use Python libraries: recordlinkage, fuzzymatcher, or thefuzz. For name standardisation before joining, use SplitForge Data Cleaner to normalize casing and spacing first.
No Automation or API Support
SplitForge is a browser tool — no REST API, CLI, or pipeline integration. Cannot be embedded in ETL workflows or scheduled jobs.
Workaround:
For automation, use Python pandas: df_left.merge(df_right, on='key', how='inner'). For cloud pipelines, AWS Glue, dbt, or any SQL database handle joins at scale with full orchestration.
Join Key Column Names Must Match
The join key column must have identical names in both files. If your files use 'customer_id' and 'CustomerID' for the same concept, you must rename one before uploading.
Workaround:
Rename columns before uploading using SplitForge Column Operations tool. Column name mapping UI is on the roadmap for a future release.
When to Use Server-Side Join Tools (SQL Databases, Python pandas, AWS Glue) Instead
You need joins in an automated ETL or scheduled pipeline
SplitForge has no API. Browser-only workflow cannot run on a schedule or be triggered programmatically.
💡 Python pandas df.merge(), dbt models with SQL JOIN, or AWS Glue transformation jobs.
You need fuzzy or approximate key matching
SplitForge only supports exact (or case-insensitive) matching. Complex match patterns require fuzzy logic.
💡 Python recordlinkage, fuzzymatcher, or PostgreSQL pg_trgm extension for trigram-based fuzzy joins.
You need to join 50M+ row files regularly
The ceiling is free disk space, not memory — but recurring jobs at that scale belong in a pipeline. Server-side tools scale horizontally and orchestrate.
💡 PostgreSQL, DuckDB, Snowflake, or BigQuery for large-scale joins. All support standard SQL JOIN syntax.
You need team-shared, version-controlled join configurations
SplitForge join settings aren't saved or shareable — each user configures from scratch each session.
💡 dbt models for SQL joins, or a shared Python script in a team repository.
Questions about limitations? Check our FAQ section below or contact us via the feedback button.
Frequently Asked Questions
How were these benchmarks measured?
What is the difference between order-preserving and key-sorted output?
How does the algorithm compare to Excel VLOOKUP?
What is the difference between join types and their performance impact?
What is the pre-join analysis step and does it affect performance?
What happens with composite key joins (multi-column)?
Can I reproduce these benchmarks?
What is the disk and memory footprint for joins?
Benchmarks last updated: June 2026 (10GB-per-side gate). Planned for re-testing after major algorithm changes.
Ready to Join CSVs Bigger Than Your RAM?
No installation. Files never uploaded. 7 join types, composite keys, explosion detection — drop your CSVs and watch a 10GB+ join run at constant memory.