The platform is the same in all three: the same engine, the same four capacity tiers and the same security model. Each installation serves one customer. The tier is chosen on paper from your table count and daily volume, before the first call.
The platform is the same in all three. The option decides who operates the infrastructure, who operates the software, and where your data lives.
| Option | Who operates the infrastructure | Who operates the software | Where your data lives | How upgrades happen | Network |
|---|---|---|---|---|---|
| 1 · Lima-managed cloudAWS, single-tenant | Lima | Lima | In an AWS account run by Lima, one installation per customer. On the showcase estate: eu-west-1, replicated to eu-central-1. | Blue-green, scheduled with you. Eight so far on the showcase estate, each with zero downtime. | VPC isolation, a web application firewall (WAF) and TLS 1.3. PrivateLink to SAP; a private link or VPN to Oracle. |
| 2 · Your cloud accountAWS or Azure | You. You keep the account, the keys and the network. | Lima installs and runs the platform inside your account. | In your own AWS or Azure account. Row data stays inside it. | Blue-green inside your account, scheduled with you. | Inside your VPC. PrivateLink or VPN to your sources, as you run them today. TLS 1.3. |
| 3 · Your data centreUbuntu 22.04 LTS hosts | You | You, with Lima support. | In your data centre, on your hosts. | Versioned releases, applied on your schedule. The previous version is kept for a one-step rollback. | Inside your network. TLS 1.3 between components. |
Read the table by row. The first row is the shortest path to production: Lima runs the infrastructure and the software, and your installation is one AWS account that serves you alone. The second row keeps the data inside an account you hold, with Lima running the software in it. The third row is for a policy that keeps everything on your own servers.
Identity, access rules and the four capacity tiers are the same in every row. The option changes who operates each layer and where the data sits.
Four tiers, from 32 to 128 vCPU. The same tiers apply in your cloud account and in your data centre.
AWS r6i.8xlarge
AWS r6i.16xlarge
AWS r6i.24xlarge
AWS r6i.32xlarge
Every tier: 1 TB+ SSD (EBS gp3) · S3 object storage as needed · Ubuntu 22.04 LTS · 100 users included per tier · Azure equivalents at each size.
Each block is one reference configuration, and the blocks grow with the tier. The name is the number of vCPU: 32C has 32 vCPU and 256 GB of memory on an AWS r6i.8xlarge instance, and 64C doubles both. 96C and 128C add cores for estates with several ERPs and scripted transforms.
The tier is chosen on paper from your table count and daily volume, before the first call. The table below is the rule we start from.
| Your estate | Tier to start on | Why |
|---|---|---|
| A few hundred tables, nightly deltas | 32C | One ERP or one warehouse, refreshed each night with the rows that changed. 32 vCPU and 256 GB hold the working set. |
| 600+ tables or 200M+ rows | 64C or 96C | The performance estimate for 615 tables and about 220 million rows across nine SAP, Oracle and PeopleSoft sources is roughly 30 minutes end to end on 64 vCPU. |
| Several ERPs with scripted transforms | 96C or 128C | In the same estimate, scripted transforms take 35 to 40 minutes on 64 vCPU. More cores bring the run inside a shorter window. |
One installation as it runs on the showcase estate: single-tenant on AWS eu-west-1, three availability zones, PrivateLink to SAP, a private link or VPN to Oracle. Your cloud account and your data centre run the same picture.
Your sources connect through a connector over TLS 1.3, the current standard for encrypted connections: SAP, Oracle, other databases, the warehouse management system (WMS), the logistics partner (3PL), files and streams. SAP connects over PrivateLink, a private AWS path that keeps the traffic off the public internet. Oracle databases connect over a private link or a VPN.
The installation itself runs in three availability zones, which are separate data centres in the same region. Each zone runs its own engine workers, its own Airflow scheduler and its own Trino query engine. All three zones share one database, one object store, one set of keys and one audit log. Targets are planning applications, the lakehouse, data products and APIs, and the return path writes results back into SAP and Oracle, each write confirmed.
| Part | What it is | What it does here |
|---|---|---|
| EKS | Kubernetes on AWS: the system that runs the platform’s containers. | Runs the engine workers, Airflow and Trino in every zone, and moves work to another node when one drops. |
| RDS | The managed database service on AWS. | Holds the catalog, the lineage, the run history and the access rules. |
| S3 | Object storage on AWS. | Holds landed data, archives and the audit logs. |
| KMS | The key management service; it holds the encryption keys. | Encrypts data at rest with keys you control. |
| WAF | A web application firewall. | Filters the requests that reach the platform’s web interface and APIs. |
| WORM audit logs | Write once, read many: storage that keeps a record from being changed after it is written. | The audit record an auditor exports is the record that was written. |
Three zones, active at the same time. One can fail and the installation keeps serving.
The three zones serve requests at the same time. When one zone fails, the platform stops sending requests to it within 30 seconds, and the other two zones carry the load. When the queries need more capacity, Trino adds workers: on the showcase estate it went from 4 workers to 12 in 90 seconds, with a ceiling of 20.
In the November 2025 AWS zone event the showcase estate re-routed on its own. The event lasted 8 minutes end to end, and the platform recovered on its own.
Two figures describe response time under load. p95 is the time within which 95 of every 100 requests were answered; p99 is the same for 99 of every 100. At 1,284 concurrent users the showcase estate measured p95 at 1.4 seconds and p99 at 3.1 seconds.
to stop sending requests to a failed zone; the other two carry the load.
Trino query workers added under load, with a ceiling of 20.
at 1,284 concurrent users.
the AWS zone event, end to end, recovered on its own.
Data is replicated to a second region, and the recovery is tested.
Every installation replicates its data to a second region. On the showcase estate the primary region is eu-west-1 in Ireland and the copy is in eu-central-1 in Frankfurt. Two figures describe what happens after an incident.
RPO is the recovery point objective: the most data the installation can lose, measured in time. It is four hours, which means at most four hours of pipeline runs to re-run from the source systems. RTO is the recovery time objective: the longest time until the installation is back in service. It is two hours.
In the Q4 2025 test the installation was restored from the archive in 1 hour 48 minutes. Pipelines keep checkpoints, the saved position of the last completed step, so a run that was interrupted resumes from that step once the installation is back.
Your directory signs people in, your keys encrypt the data, and your private network path reaches SAP and Oracle.
Sign-in goes through your identity provider. SSO, single sign-on, means a user signs in once with the company account and reaches Lima with that session. SAML 2.0 is the standard used for it, and Azure AD, Okta and LDAP are supported. SCIM is the standard that copies users and groups from your directory into Lima and removes them when they leave. Inside Lima, access rules decide which rows and columns each person may see, by role and by attributes such as region or plant.
Programs reach the APIs with scoped API keys and OAuth, so each key can do one job. Encryption uses your KMS keys, TLS 1.3 protects every connection, and the installation sits in its own VPC. SAP is reached over PrivateLink. Oracle databases are reached over a private link or a VPN.
| What you bring | What Lima provides |
|---|---|
| Your identity provider: Azure AD, Okta or LDAP, with your groups and roles. | SSO through SAML 2.0, SCIM sync of users and groups, and role- and attribute-based access rules at row and column level. |
| Your encryption keys, held in KMS. | Encryption at rest with those keys, TLS 1.3 on every connection, and credentials kept in a vault. |
| The private path to your ERPs: PrivateLink to SAP, a private link or VPN to Oracle. | Connectors that use that path, VPC isolation, a web application firewall, and audit logs on WORM storage. |
| For option 2, your AWS or Azure account. For option 3, your hosts on Ubuntu 22.04 LTS. | The installation, its upgrades and its runbooks, and the security packet with the controls listed. |
The security packet: architecture, controls, certification status and dates →
From contract to full production on the showcase estate, week by week.
The showcase estate went from contract to full production in 22 days. Week 1 connected five sources and discovered 4,284 assets: SAP through RFC and change capture on day 1, Oracle over JDBC and the warehouse system over REST on day 2, Snowflake and the logistics partner on day 3, and schema mapping, lineage and the first query on day 4.
Week 2 put the rules in place: 8 certified views, 12 quality rules, and personal data (PII) tagged so that the column-level access rules apply from the start. Week 3 published the first data products. Week 4 handed sign-in to the customer’s directory, with SSO and SCIM for 49 users, and moved the existing pipelines from the legacy scheduler. Day 22 was full production.
Deployment is the first step of those 22 days. The reference configuration is chosen before the contract, so week 1 starts with connections. A Backbone first load is a separate four-week offer: one dataset into one target, with a reconciliation report at the end. Run your first load →
How a new version arrives, how a configuration change travels to production, and the four runbooks.
An upgrade runs blue-green. The new version comes up beside the running one, in its own environment. It takes the traffic once its checks pass, and the old environment stays in place for a one-step rollback. The showcase estate has had 8 upgrades this way, each with zero downtime.
A configuration change is versioned and promoted from dev to staging to production, with a named approval at each gate: pipelines, run windows, quality rules and grants. A change that misbehaves in production is rolled back in one step, because the previous version is still there.
Blue is the current version, kept for a one-step rollback. Green is the new version, which takes the traffic after its checks pass.
An approval gate at each step, and a one-step rollback to the previous version.
| Runbook | How it runs | What it does |
|---|---|---|
| Connector restart | Fully automatic | Restarts a connector that stopped responding. |
| PII cache invalidation | Fully automatic | Clears the cache that holds tagged personal data, so a changed tag applies at once. |
| Trino scale-out | One click | Adds query workers, up to the ceiling of 20. |
| Pipeline emergency pause | One click | Pauses a pipeline and keeps its checkpoint, so it resumes from the same place. |
Compute cost by team and by pipeline, every month.
Compute cost is attributed to the team and the pipeline that used it, so a platform owner can see what each team’s pipelines cost each month. Query results are cached, and a query answered from the cache uses no compute. February 2026 on the showcase estate is in the table.
| February 2026, showcase estate | Amount | Note |
|---|---|---|
| AWS compute, attributed to teams and pipelines | £4,820 | The month’s compute across all pipelines and queries. |
| Saved by the query cache | £1,840 | 74% of queries were answered from the cache. |
Deployment is the ground the six steps run on. Connect, extract, transform, load, orchestrate and return all run on the same installation, in whichever of the three ways you choose.
Yes. In your own cloud account, the installation sits in your VPC and row data stays inside it. In your data centre, every component runs on your hosts and TLS 1.3 protects the connections between them. Lima supports the platform in both cases; the support terms are in the security packet.
The installation serves you alone, in an AWS account run by Lima. People reach it through your identity provider and the access rules you set, and actions on the platform are recorded in audit logs on WORM storage. The operating controls Lima applies to the infrastructure are listed in the security packet.
A new version comes up in its own environment beside the running one. It takes the traffic once its checks pass, and the old environment stays for a one-step rollback. Configuration changes go through dev and staging first, with an approval at each gate. The showcase estate has had 8 upgrades this way, each with zero downtime.
An AWS or Azure account with a VPC for the installation, an instance at one of the four reference configurations, your KMS keys, your identity provider for SSO and SCIM, and a private path to your sources: PrivateLink to SAP, a private link or VPN to Oracle. Lima installs and runs the platform inside the account.
SAP connects over PrivateLink, a private AWS path, and is read through released function modules, BAPIs, CDS views and application-level change capture. Oracle databases connect over a private link or a VPN and are read through JDBC with a read-only database user, with LogMiner change capture where the DBA allows it. Both connections use TLS 1.3. The extraction methods for SAP and Oracle →
Architecture, controls, the SAP extraction statement and the AI data boundary, with certification status and dates, and how to request reports under NDA.
