The same engine runs a 10 GB nightly delta, the rows that changed since the night before, and a multi-terabyte migration. Capacity is chosen as a tier of vCPU and memory, from 32 to 128 vCPU on one node. The subscription is sized by that capacity, so the volume you move does not change the price.
Scale has three dimensions on this page: volume, breadth and speed.
10 GB · 12M rows · lab run
~30 GB · 220M rows · estimate
80 GB a day · production
615 tables from 9 systems · estimate
4,218 SAP tables · showcase estate
2,891 Oracle tables · showcase estate
15 min · 10 GB · lab run
~30 min · ~30 GB · estimate
~55 min · scripted transforms · estimate
Volume is how much data a run moves, counted in rows and gigabytes. Breadth is how many tables and source systems the run touches. Speed is how fast the run must finish so that the next business step can start; the period it must finish in is the run window.
A job can be large in one dimension and small in another. A nightly delta from one ERP is small in volume and breadth and tight on speed. A migration is large in volume and breadth, and its run window is measured in hours or days. The rest of this page shows how the engine handles each dimension.
Every combination of transform pattern and data movement runs on the same engine.
| Transform ↓ · Movement → | Full batch whole table each run | Incremental rows past a marker column | Change capture each change as it happens | Streaming stream micro-batches |
|---|---|---|---|---|
| ETLtransform in Lima’s engine | supportedplanning first load | supportednightly delta | supportedstock positions | supporteddispatch events |
| ELTland raw, transform in the warehouse | supportedraw landing | supporteddaily append | supportedorder changes | supportedevent landing |
| A mixlight clean in Lima, heavy work in the warehouse | supportedmigration | supportedweekly refresh | supportedmaster data | supportedWMS webhooks |
Twelve combinations of transform pattern and data movement, all supported. The example in each cell is a typical job of that kind. The rows say where the transform runs. In ETL the data is transformed in Lima’s engine and loaded finished. In ELT the raw data lands first and the warehouse transforms it with its own compute. A mix does a light clean in Lima and the heavy transforms in the warehouse.
The columns say how the data moves: the whole table each run, only the rows past a marker column, each insert, update and delete as it happens, or micro-batches from a stream. The pattern is a setting on each pipeline. The volume is a tier. ERP sources such as SAP and Oracle, and file, database and stream sources, all use the same patterns.
A load fans out into jobs, worker threads and lookup queries, and the export reuses the same CPUs.
The engine is built on Apache Spark and Apache Ignite. Spark runs the parallel transform; Ignite holds the working data in memory across the nodes. Kubernetes, the system that runs the engine’s containers, restarts a failed task on another node, and the run continues from that task.
A run has three stages: import, transform and export. The bars show the minutes in each.
On the estimate, import takes 8 to 10 minutes, a simple transform 8 to 9 minutes and export about 10 minutes, so the run closes in about 30 minutes. With scripted transforms in Python the transform stage grows to 35 to 40 minutes and the run closes in about 55 minutes. The lab run of 10 GB took 6, 3 to 4 and 6 minutes: 15 minutes in all.
Import is the read from the source into Lima. Export is the write from Lima into the target. The transform stage is the one that changes most with the work asked of it, which is why the scripted row is longer.
Capacity comes in four tiers. Each tier is one node with a set number of vCPU and amount of memory.
To scale up, you change the tier, and the same pipelines run on the larger node. To scale out, a job asks for more nodes and Kubernetes adds them for the run. Estates of 600+ tables and 200M+ rows usually start at 64 or 96 vCPU. A nightly delta from one ERP fits on 32 vCPU.
Every tier includes the whole platform and 100 users, with 1 TB or more of SSD, the fast local disk, and object storage as needed. The same tiers apply in Lima’s cloud, in your own cloud account and on your own servers. Deployment options and reference configurations →
The subscription is sized by the estate and the tier you run on.
There is no charge per row, per connector, per run or per question. A migration month costs the same as a quiet month on the same tier, so a large migration can be planned on a known budget. When a migration needs a larger tier for its duration, the tier is the only thing that changes.
Fixed-price entry offers give a trial a clear end point: a free extraction assessment, a four-week first load with a reconciliation report, a fixed-price migration conversion, and a per-system archive-and-decommission. Pricing principles and entry offers →
A long run keeps checkpoints, so an interruption costs the time since the last checkpoint.
Every run saves a checkpoint after each completed part, such as a table or a partition. After a network fault, a source outage or a quality hold, the run resumes from the last checkpoint, replays the changes it missed in order, and applies each change once, because every write carries a key and a retry updates the row in place. At the end, rows in and rows out are compared per table, along with control totals on key amount columns, and any differences are listed for sign-off.
On the showcase estate, a quality hold of 44 minutes ended with 841K events replayed in order and the 06:30 deadline met with 3h 32m to spare. A six-hour archive extract interrupted at hour four resumes at hour four.
Every figure carries the label of where it comes from.
The table gathers every throughput figure on this page in one place. The last column says where each one comes from. Lab runs are ours; the estimate is a performance estimate for a prospect’s volumes; production figures are customer estates; the two client examples have been reported to us and are still to be verified.
| Workload | Volume | Configuration | Result | Where the figure comes from |
|---|---|---|---|---|
| Lab run12 tables | 12M rows · 10 GB | 64 vCPU | 15 min: import 6, transform 3–4, export 6 | Lab run |
| Nine-source planning loadSAP × 6 · Oracle EBS · PeopleSoft | 220M rows · 615 tables · ~30 GB | 64 vCPU: 24 for import, 44 for the transform | ~30 min with simple transforms; ~55 min with scripted transforms | Estimate |
| Daily production movement | 80 GB a day | Semiconductor enterprise estate | Every day, inside its run window | Production |
| Change capture from two ERPsSAP S/4HANA · Oracle ERP | 32 GB a day from 4,218 SAP tables · 18 GB a day from 2,891 Oracle tables | Single-tenant installation on AWS | Copies kept current through the day by change capture | Showcase estate |
| Client example | 14 GB | 32 cores | Under 30 minutes | Client example · unverified |
| Client example | 20 GB | 48 cores | 45 minutes | Client example · unverified |
| Parallel loads in and out | 25M+ rows | One engine, loads running side by side | Supported by the engine | Product |
The Backbone Benchmark: method published now, results next quarter →
Your ERP keeps running while Backbone reads it, because the number of parallel reads is capped per system.
An ERP is the system that holds orders, stock, materials and finance. Backbone reads it in parallel, and the amount of parallel work is agreed with the team that runs the ERP, so the ERP keeps serving its users while the read runs. The table sets SAP and Oracle side by side.
| SAP ECC and S/4HANA | Oracle E-Business Suite (EBS) and Oracle ERP | |
|---|---|---|
| How parallel reads are capped | Parallel sessions are capped per system and per run window. The cap is agreed with the Basis team, the team that administers SAP. | Partitioned JDBC reads are capped per connection. JDBC is the standard database connection; a large table is split into partitions that are read side by side. The cap is agreed with the database administrator (DBA). |
| What keeps the daily volume small | Change capture reads only the rows that changed, through change pointers, table-level change capture, delta-enabled CDS views (database views that SAP defines and releases) and extractor delta queues. On the showcase estate SAP S/4HANA sends 32 GB a day across 4,218 tables. | Incremental reads by a last-update column and, where the DBA allows it, LogMiner, Oracle’s own reader of the database change log. On the showcase estate Oracle ERP sends 18 GB a day across 2,891 tables. |
| How a first load or a migration runs | Tables are read in partitions inside the agreed session cap, many tables at a time. Each partition gets a row count check. | Tables are read in partitions over the agreed number of connections, many tables at a time. Each partition gets a row count check. |
The largest documented runs are about 220M rows across 615 tables in about 30 minutes on 64 vCPU (estimate) and 80 GB a day (production). A multi-terabyte migration is sized on request: the tables are read in partitions, each partition gets a count check, and the run is spread over the nodes and the run windows the estate allows. The method for the public benchmark is published now and the results follow next quarter.
It resumes from its last checkpoint. The changes missed during the interruption are replayed in order and each is applied once, because every write carries a key and a retry updates the row in place. The reconciliation report at the end shows rows in, rows out and control totals per table.
The subscription is sized by the estate and the tier. A migration month on the same tier costs the same as a quiet month. When the migration needs a larger tier for its duration, the tier is the only thing that changes, and the price returns with the tier afterwards.
Estates of 600+ tables and 200M+ rows usually start at 64 or 96 vCPU. 96 vCPU suits scripted transforms at volume and archive extracts. 128 vCPU suits terabyte migrations and decommissioning runs, and serves as the head of a multi-node cluster. A nightly delta from one ERP fits on 32 vCPU.
The number of parallel reads is capped and agreed with the team that runs the ERP: parallel sessions per system and per run window on SAP, agreed with the Basis team; partitioned reads per connection on Oracle, agreed with the DBA. Large reads run inside the run window agreed for them. Change capture keeps the daily volume small: 32 GB a day from SAP and 18 GB a day from Oracle on the showcase estate.
Tell us the tables, the rows and the run window. An architect answers with the tier, the pattern per pipeline and the timings to expect, before anything is installed.
