Skip to main content

​
Overview

The LDB (Linked-list Database) is a headless (no user interface or client layer) database engine at the core of SCANOSS. It is designed for single-key, read-optimised access across large volumes of data, whilst maintaining a minimal memory and disk footprint and minimising kernel-level system calls. Data is structured using linked lists. SCANOSS SaaS runs on a distributed infrastructure built around the LDB. The platform uses load balancing and distributed LDB data nodes to process software analysis requests at scale, ensuring high availability and fault tolerance.

​
How Load Balancing Works

Incoming requests are distributed across multiple processing nodes. Each processing node runs the SCANOSS Engine and queries a shared LDB Knowledge Base — a read-optimised store of open source component data — to match file fingerprints (cryptographic hashes of source code snippets) against known open source components. This architecture provides:
  • Even workload distribution across processing nodes
  • High availability through redundancy
  • Horizontal scaling to handle increased request volumes

​
Example Deployment Scenario

A typical large enterprise deployment includes the following layers:
  1. External request endpoint — receives incoming scan requests
  2. Load balancer — distributes requests across processing nodes
  3. Processing nodes — each running the SCANOSS Engine
  4. LDB Knowledge Base — shared, read-optimised data layer queried by all nodes

​
Architecture Diagram

​
Reliability and Scalability Properties

This architecture is designed to provide:
  • Fault tolerance — redundant processing nodes prevent single points of failure
  • Consistent query performance — read-optimised data access at the LDB layer
  • High availability — load balancing ensures continuity under node failure
  • Horizontal scaling — additional processing nodes can be added without downtime

​
LDB and Engine Version Compatibility

LDB and the SCANOSS Engine ship as two parallel release lines that must be upgraded together:
  • Traditional line — LDB 4.x and Engine 5.x (for example, tag v5.5.1).
  • CRC64-compatible line — LDB 5.x and Engine 6.x and later, tagged with a mandatory -crc64 suffix (for example, v5.0.0-crc64, v6.0.0-crc64).
A CRC64-line LDB requires an Engine from the CRC64 line, and vice versa: an Engine from before 6.0.0-crc64 cannot read tables built by LDB 5.x-crc64, and doesn’t link against its library API. This applies to the on-disk table layout and library API surface, not to which hash a table actually uses, a CRC64-line deployment can still run MD5-hashed tables. Engine validates the LDB version it built against and the one it’s running against, and refuses to start on a mismatch rather than failing unpredictably later. ldb -v, scanoss -v, and the JSON server.version field all report which line a binary belongs to, check these when planning an upgrade.