In-process vs Docker-backed engines
Most of Loopback's 117 emulated services run as fast in-process handlers inside the GraalVM-native emulator binary. Shared in-memory state keeps latency low — list-table calls complete in microseconds — and makes snapshots trivial: export serializes the same stores the handlers read and write. This is the default path for S3, DynamoDB, SQS, IAM, Blob Storage, Pub/Sub, and dozens of other wire-compatible APIs.
Services marked with a dot on the Features page escalate to Docker-backed engines when fidelity demands real processes: Lambda runs in containerized runtimes, RDS spins up actual Postgres, OpenSearch launches real nodes, EKS and GKE talk to local cluster APIs, Cosmos DB and Azure SQL use real database containers. The router selects the backend per service at request time; SDKs, CLIs, and IaC see identical API shapes and error codes either way.
The engineering trade-off is explicit: in-process for speed and determinism in CI, Docker when behavioral semantics depend on a real runtime or database engine. Compatibility tests in the repo exercise both paths against production SDKs so regressions surface before users hit them.