Compute Resource Recommendations

Sombra instances are largely stateless, meaning they can easily be scaled both vertically and horizontally. Sombra is built to be resilient to downtime in many use cases such as discovery & classification and data privacy requests, though there are also cases like Preference Management where Sombra uptime is critical for proper handling of synchronous user requests.

This document covers the minimum requirements to get started with running Sombra, our recommended production configuration, autoscaling guidance, and detailed sizing recommendations based on which Transcend products you use.

The table below shows the bare minimum resources required for Sombra to start up and handle requests. These are suitable for development, testing, or very low-volume production environments.

Important: The LLM Classifier is a separate service from Sombra and requires its own dedicated GPU-enabled compute. It is not required unless you are using content classification or unstructured discovery.

For most production deployments, we recommend the following as a safe starting point that will handle the majority of workloads without further tuning:

This configuration provides:

• High availability through multiple instances across availability zones
• Headroom for traffic spikes without manual intervention
• Sufficient memory for large file processing (Google Drive, AWS S3, databases)
• Cost efficiency through autoscaling — you only pay for what you use

For a rough cost estimate, see Self-Hosting Costs. A baseline 2-instance Fargate deployment (2 vCPU, 5 GB each) runs approximately $150/month for compute alone.

Our recommended hosting options, such as our Kubernetes Helm chart or our AWS ECS Fargate Terraform module, include autoscaling configurations out of the box. You can always adjust the limits to match your needs.

Here is an example of an autoscaling configuration in our Sombra Helm chart.

• Set a high but bounded upper limit on instance count to prevent runaway costs while ensuring availability.
• Use request count per target as the scaling trigger for latency-sensitive workloads (Preference Management).
• Use memory utilization as the scaling trigger for batch workloads (DSRs, Discovery & Classification).
• Configure scale-in cooldown periods of at least 5 minutes to avoid flapping.
• Due to Sombra's ability to scale either horizontally or vertically, you have many options on how to handle scaling. Using a proper autoscaling configuration helps ensure Sombra servers are highly available while keeping costs proportional to usage.

Different Transcend products place different demands on Sombra. Use the guidance below to adjust your resource allocation based on which products you have enabled.

DSR processing is Sombra's most common workload. Each DSR triggers requests to your connected data systems (SaaS vendors, databases, internal APIs) and processes the results.

Key considerations:

• DSR processing is asynchronous and resilient to temporary Sombra downtime. If instances are overloaded, integration plugins will retry automatically.
• Systems with large individual files (Google Drive, AWS S3, certain databases) benefit from vertical scaling (more RAM per instance) rather than just adding more instances.
• You can start with the minimum and scale up as needed. Overloaded instances will produce 500 errors in your action items, which is your signal to increase resources.

Discovery & Classification scans your connected systems to build an inventory of where personal data lives. This encompasses two types of work:

• Schema discovery identifies the structure of your data systems — tables, columns, fields, and their relationships.
• Content classification examines actual data values to classify them by data category (e.g., email address, SSN, date of birth).

Scans can be resource-intensive depending on the breadth of your data systems and how many are being scanned concurrently.

Key considerations:

• Discovery scans run in the background and are resilient to Sombra restarts — scans will resume where they left off.
• Content classification samples a limited number of rows per column (not full table scans), so raw row count is generally not a scaling concern. The main driver of resource usage is schema breadth — the number of columns and subdatapoints being classified across your systems.
• When non-null sampling is enabled, Sombra may perform additional sampling passes to find non-null values for columns with sparse data, which increases resource usage.
• Scan frequency matters: if you run daily scans across dozens of systems, size toward the upper end.
• Discovery and DSR workloads share the same Sombra instances. If you run both, size for whichever is more demanding.
• Unstructured discovery (scanning file stores, document repositories, etc.) requires the LLM Classifier to be deployed. See the LLM Classifier documentation for its specific hardware and deployment requirements.

Preference Management handles synchronous API requests from your applications to read and write user consent preferences. Unlike DSRs and discovery, these requests are latency-sensitive — your end users are waiting for the response.

Key considerations:

• Sombra uptime is critical for Preference Management. Unlike DSRs, there is no built-in retry — if Sombra is down, preference reads/writes will fail for your end users.
• Autoscaling should be configured with aggressive scale-out (short cooldown periods, low request-count thresholds) to handle traffic spikes.
• We recommend always having at least 2 instances across separate availability zones for high availability.
• Monitor request latency (p95, p99) in addition to CPU/memory. If latency degrades, scale out horizontally before scaling up vertically.

If you are running multiple Transcend products through the same Sombra deployment, size your instances for the most demanding use case rather than summing the requirements. The table below provides quick reference for common combinations:

Note: The LLM Classifier always runs as a separate service with its own GPU-enabled compute and does not affect Sombra instance sizing. See LLM Classifier for its resource requirements.

If you have strong requirements for high availability and want to minimize operational overhead, use the following configuration:

This setup will handle virtually any production workload we have seen, including high-volume DSRs, large-scale discovery & classification, and heavy Preference Management traffic. With autoscaling, you will not hit the upper instance limits unless demand requires it, keeping costs proportional to actual usage.