Palantir Workload Performance Tuning

Overview

Identify whether delay comes from build scheduling, compute, data shape, transaction history, query breadth, network concurrency, or interactive replicas. Change one layer at a time and retain output parity and access controls.

Prerequisites

• Name the workload owner, service/data objective, representative window, exact build/query/module, and correctness tolerance.
• Capture queue time, duration, CPU, memory, input/output volume, retries, pagination, selected properties, and replica behavior.
• Read references/official-docs.md and confirm required engine features before changing compute.
• Prepare a sandbox branch or non-production application and a repeatable benchmark.

Current Contract

• Foundry build metrics show requested and observed CPU/memory and can distinguish scheduling from execution constraints.
• Single-node and Spark engines support different features; Polars is recommended for many production single-node transforms but is not universally interchangeable.
• Incremental histories can become progressively slow and may require a snapshot build.
• OSDK query performance depends on filters, selected properties, pagination, links, aggregations, and subscription shape.