Palantir Gotham and Palantir Foundry are often described as separate products: Gotham for defense and intelligence, Foundry for commercial enterprises. That distinction is directionally useful, but it is no longer a complete technical picture.
Gotham provides specialized applications for mission planning, geospatial awareness, link and graph analysis, intelligence workflows, and operational coordination. Foundry provides the data operations, logic, Ontology, analytics, workflow, and application-development capabilities used across industries. Palantir now documents its defense offerings—including Gotham’s core multimodal applications—as integrated with the standard AIP, Foundry, and Apollo architecture.
The practical buying question is therefore not always “Gotham or Foundry?” It may be “Which mission applications do users need, and which shared platform services must support them?” A government agency may use both. A manufacturer may need Foundry without Gotham. A mission team may interact mostly with Gotham even when Foundry manages the underlying Ontology.
This Palantir Gotham vs Foundry comparison covers capabilities, architecture, security, AI, workflows, deployment, interoperability, pricing, and use cases. Product information was checked against official Palantir documentation on September 23, 2026. Availability and commercial terms vary by enrollment, environment, and contract.
Quick takeaway: Gotham is a specialized mission-operations application suite. Foundry is the broader data and operational platform underneath enterprise analytics, Ontology development, applications, and workflows. Modern deployments can combine them rather than choose only one.

What Is Palantir Gotham?
Palantir Gotham is a software platform and application suite built for defense, intelligence, law-enforcement, and other high-stakes operational missions. It integrates diverse information—such as reports, entities, relationships, geospatial data, tracks, imagery, video, and sensor feeds—so analysts and operators can investigate activity and maintain a shared operational picture.
Gotham’s value is not simply storing data. Its applications are designed around mission workflows. An analyst can discover relationships across people, organizations, places, events, and documents. An operator can view changing conditions on a map, compare a plan with live sensor information, coordinate activity, and record decisions. Palantir’s official Gotham operations paper describes a live common operating picture built from historical and streaming data.
Common Gotham application patterns include:
- Geospatial operations: Maps, tracks, overlays, alerts, and time-aware views.
- Graph analysis: Entities and links for investigating networks and relationships.
- Multimodal intelligence: Documents, imagery, video, signals, structured records, and observations in one workflow.
- Mission planning: Courses of action, coordination, tasking, and feedback from execution.
- Edge operations: Software and data workflows that may need to work with intermittent or disconnected connectivity.
- Developer integration: APIs for building applications on Gotham resources and workflows.
The Gotham API exposes REST endpoints using OAuth 2.0. Its documented resources include RevDB, an object database backed by a dynamic ontology, along with domain-specific interfaces. Exact applications and APIs available to a customer depend on deployment and authorization.
Gotham should not be reduced to a generic dashboard. Its differentiation is a set of opinionated operational tools for environments where users must interpret incomplete information, collaborate across classification boundaries, and update a live mission picture.
Get Started with Theresa for FREEWhat Is Palantir Foundry?
Palantir Foundry is the foundational data operations platform in Palantir’s current architecture. It connects source systems, transforms and manages data, authors logic, develops an Ontology, supports analytics, and delivers workflows and applications. AIP adds generative-AI models, agents, automation, and evaluation; Apollo manages deployment and upgrades.
Foundry’s central concept is the Ontology. It represents an organization using objects, properties, relationships, functions, actions, and security policies. A supply-chain Ontology may model factories, production lines, inventory, suppliers, orders, and shipments. A government Ontology may model units, assets, locations, events, observations, and readiness. Applications can reuse those definitions instead of recreating domain meaning from tables.
Palantir’s architecture overview groups Foundry capabilities into three service layers:
- Data services: Connectivity, transformation, virtualization, storage, health monitoring, and data management.
- Logic services: Business rules, models, optimization, model operations, and external compute.
- Workflow services: Interactive applications, event-driven automations, scheduled work, and low-code or pro-code development.
Those services connect to the Ontology Language, Engine, and Toolchain. Analysts can use Foundry applications for tabular, graph, geospatial, time-series, and object analysis. Builders can create operational interfaces in Workshop or Slate, custom applications with the Ontology SDK, and AI workflows with AIP. The Foundry application reference documents the current analytical and development surfaces.
Foundry is used in both commercial and government environments. It is not “the civilian version of Gotham.” It is the general data and operational foundation that can support industry-specific offerings, custom applications, and Gotham itself.
Get Started with Theresa for FREEPalantir Gotham vs Foundry: At a Glance
| Dimension | Palantir Gotham | Palantir Foundry |
|---|---|---|
| Primary role | Specialized mission applications and operational workflows | Foundational data operations, Ontology, analytics, and application platform |
| Typical users | Intelligence analysts, mission planners, operators, commanders, investigators | Data engineers, analysts, data scientists, application builders, operators, business teams |
| Core experience | Maps, graphs, multimodal intelligence, mission planning, shared operational picture | Pipelines, datasets, Ontology, analytics, models, applications, workflows, actions |
| Data model | Gotham resources and operational objects; can consume mapped Foundry objects | Foundry-managed Ontology of data, logic, actions, and security |
| AI | AI-assisted analysis and mission workflows; can use AIP capabilities | Model integration, AIP agents, logic, evaluations, and AI application development |
| Analytics | Mission-focused geospatial, temporal, graph, and multimodal analysis | General tabular, object, geospatial, temporal, BI, data-science, and operational analytics |
| Security | Built for highly sensitive and classified mission environments | Granular mandatory and discretionary controls across data, Ontology, applications, and workflows |
| Deployment | Government cloud, on-premises, edge, and disconnected mission environments | Cloud, on-premises, and disconnected environments managed through Apollo |
| Pricing | Contract-specific; depends heavily on mission scope and environments | Contract-specific; platform usage can include compute, storage, and Ontology volume |
| Best fit | Defense, intelligence, public safety, and mission coordination | Cross-industry data integration, decision applications, AI, and enterprise operations |
The cleanest distinction is specialized applications versus foundational platform. Gotham packages mission-oriented experiences. Foundry supplies reusable data, logic, governance, and application services.
Get Started with Theresa for FREEPalantir Gotham vs Foundry: Key Differences
Mission workflows versus general enterprise workflows
Gotham begins with the operational needs of analysts and mission users. Its maps, graphs, media tools, planning interfaces, and shared operational views are designed to work together during investigation and execution.
Foundry begins with an organization’s data and decision infrastructure. Its users build pipelines, define objects and actions, create analytics, deploy models, and assemble applications for many domains. A Foundry application can support a defense workflow, but Gotham provides more prebuilt mission-specific interaction patterns.
Application suite versus application-building platform
Gotham is experienced primarily through domain applications. Foundry also includes applications, but a major part of its value is enabling teams to build and govern new ones. Workshop, Slate, the Ontology SDK, platform APIs, and developer tooling provide different levels of abstraction.
The implication is operational. A Gotham program may focus on configuring mission capabilities and connecting them to authoritative data. A Foundry program may devote more effort to building the data model, logic, applications, release process, and ownership model for many use cases.
Specialized multimodal analysis versus broad analytics
Gotham emphasizes geospatial, temporal, link, entity, sensor, document, imagery, and video analysis inside a common operational context. Foundry offers broad analytics across datasets and Ontology objects, including point-and-click analysis, dashboards, spreadsheets, code workspaces, time series, and external BI integrations.
Both can display maps and graphs. The distinction is not a missing chart type; it is how tools are packaged around the user’s workflow.
Product boundary versus shared architecture
Older descriptions often treat Gotham and Foundry as separate stacks. Palantir’s current platform architecture documentation states that its defense offerings are integrated with the standard AIP, Foundry, and Apollo architecture, and that Gotham’s core applications can be powered by a Foundry-managed Ontology.
This means product names do not always identify separate data copies or security systems. A deployment can map Foundry object types into Gotham, carry security controls with the data, and let users move context between applications.
Target environment
Gotham is associated with classified, coalition, tactical, and edge use cases where connectivity and accreditation constraints can be unusually demanding. Foundry also operates in regulated and classified environments, but its scope spans government and commercial enterprises.
Apollo underpins delivery across cloud, on-premises, and disconnected environments. Palantir’s Apollo documentation separates deployment management from the application itself. During architecture review, identify where the platform runs, where each data source resides, and which capabilities remain available when links fail.
Get Started with Theresa for FREEGotham vs Foundry: Core Architecture
A simplified Gotham architecture has four layers:
- Mission sources: Reports, sensors, tracks, documents, imagery, video, and external operational systems.
- Object and knowledge layer: Entities, events, documents, links, locations, temporal state, and provenance.
- Mission applications: Geospatial awareness, graph investigation, multimodal analysis, planning, and coordination.
- Operational feedback: Decisions, observations, updates, tasking, and model feedback returned to the shared data foundation.
Gotham’s user experience is optimized around the top two layers: mission objects and applications. The platform still needs ingestion, transformation, indexing, security, audit, deployment, and integration services underneath.
A simplified Foundry architecture also has four layers:
- Data services: Connect, ingest, virtualize, transform, store, monitor, and govern data.
- Ontology system: Model objects, relationships, logic, actions, and security in a decision-centric representation.
- Analytics and development: Notebooks, point-and-click analytics, models, dashboards, AIP workflows, SDKs, and low-code builders.
- Applications and actions: Human and agent workflows that read operational state, request changes, and write results back to source systems.
Foundry’s Ontology is more than a read-only semantic layer. Palantir describes it as an integration of data, logic, action, and security. Its Engine supports queries, subscriptions, durable updates, batch mutation, streaming, and change-data-capture patterns. See the Ontology system documentation.
Security is not a separate afterthought in either product. Palantir’s security overview describes Organizations, Markings, classification-based access controls, roles, restricted views, object policies, and property policies. Mandatory controls can propagate with derived data. A deployment must still test permissions at every application, export, API, and write path.
Get Started with Theresa for FREECan Gotham and Foundry Work Together?
Yes. Palantir documents several explicit interoperability patterns. A Foundry object type can be enabled for Gotham integration and mapped into a corresponding Gotham category such as Entity, Event, or Document. Foundry’s Ontology Manager then reports the installation state. The Gotham integration documentation states that mapped Foundry data carries its access controls and classification markings into Gotham.

A combined flow can look like this:
- Foundry connects approved operational, enterprise, and sensor sources.
- Pipelines normalize identifiers, timestamps, geospatial fields, provenance, and quality signals.
- The Foundry Ontology represents governed objects, relationships, functions, and actions.
- Type mapping exposes selected objects to Gotham applications with compatible security markings.
- Gotham users analyze those objects in map, graph, and mission workflows.
- Foundry users work with the same domain through analytics, Workshop modules, AIP agents, or custom applications.
- Approved actions and user feedback update the operational state and downstream systems.
Palantir also documents cross-application interactivity. Applications can share context through drag-and-drop, app pairing, and commands. If Gotham and Foundry hold synonymous representations of the same real-world object, type mapping and data enrichment can translate identifiers between them.
Integration still requires design work. Teams must define authoritative identifiers, mapping ownership, synchronization behavior, latency targets, conflict resolution, export policy, and recovery after partial writes. “Available in both products” does not guarantee that two objects are current, semantically identical, or safe to update.
Get Started with Theresa for FREEGotham vs Foundry: Pricing
Palantir does not publish a universal Gotham or Foundry price list. Both are typically sold through contract-specific enterprise or government agreements. Pricing can depend on users, mission scope, environments, data volume, compute, applications, support, implementation, and commercial commitments.
Foundry exposes usage through Resource Management. The current usage documentation describes:
- Foundry compute: Batch, interactive, and continuous work measured in compute-seconds.
- Foundry storage: General platform storage measured in gigabyte-months.
- Ontology volume: Indexed Ontology storage measured in gigabyte-months.
- Application-driven usage: Queries, transformations, indexing, actions, analytics, models, and AI workflows can add compute.
These meters explain consumption; they are not a complete public contract quote. Existing enterprise terms may use different rates or commitments.
Gotham costs can be shaped by additional factors such as specialized mission applications, classified or disconnected environments, edge infrastructure, accreditation, integration with sensors and command systems, training, and operational support. Ask the vendor to separate recurring software, platform consumption, cloud or hardware infrastructure, implementation, and optional services.
Use a full-cost model:
total cost = software + platform usage + infrastructure + integration + deployment + operations + support
Compare cost per accepted mission or business outcome, not only per user. A platform that shortens investigation time but requires extensive data remediation may have a different cost curve from a narrow application with less integration scope.
Get Started with Theresa for FREEGotham vs Foundry: Pros and Cons
| Product | Advantages | Watchouts |
|---|---|---|
| Gotham | Purpose-built mission applications; strong geospatial, graph, temporal, and multimodal workflows; designed for sensitive environments; live operational picture; can consume Foundry-managed objects | Highly specialized; configuration and integration can be complex; pricing is not public; may be excessive for general commercial analytics; exact capabilities depend on enrollment and authorization |
| Foundry | Broad data integration and transformation; reusable Ontology; analytics, model, AIP, workflow, and application tooling; cross-industry fit; can power Gotham applications | Requires sustained platform and domain ownership; teams must design the Ontology and applications; broad scope can increase implementation effort; contract and usage economics require careful modeling |
The strongest argument for Gotham is not that it has maps or graphs; many products do. It is the integration of those surfaces into mission workflows under a common security and deployment model. The strongest argument for Foundry is not that it performs ETL; it is the combination of data, logic, actions, security, and application delivery around an operational Ontology.
Get Started with Theresa for FREEPalantir Gotham vs Foundry FAQs
Is Gotham built on Foundry?
Modern Palantir documentation says Gotham’s core multimodal applications and tools can be powered by a Foundry-managed Ontology and are integrated with the standard AIP, Foundry, and Apollo architecture. That does not mean every Gotham component is simply a Foundry screen. Gotham retains specialized mission applications, resources, and APIs.
Is Gotham only for the military?
Gotham is strongly associated with defense and intelligence, but its investigation, public-safety, and operational-coordination patterns can extend to other government missions. Foundry is the broader cross-industry platform. Procurement and access restrictions determine which offerings are available.
Can a commercial company buy Gotham instead of Foundry?
Theoretically, product availability is a sales and eligibility question. Architecturally, most commercial data, analytics, AI, and operations programs align more naturally with Foundry because it is designed as the general data operating platform. Gotham is valuable when its specialized mission workflows are the requirement.
Do Gotham and Foundry use the same Ontology?
They can share or map operational concepts, but architects should not assume automatic identity. Foundry supports type mapping into Gotham, and cross-application enrichment can resolve synonymous objects. Teams still need to govern identifiers, mappings, synchronization, security, and lifecycle changes.
Which product includes AIP?
AIP is Palantir’s generative-AI platform and integrates with the standard Foundry architecture. Gotham offerings can use AI capabilities within mission workflows. Confirm which models, agents, evaluations, and application features are enabled in the specific enrollment and deployment.
Which product has stronger security?
Both are designed for sensitive and regulated environments and can participate in the same platform security model. Gotham’s mission deployments often operate under demanding classification and connectivity constraints. Foundry provides granular controls across data, Ontology resources, applications, and actions. Security strength ultimately depends on configuration, accreditation boundary, identity integration, data markings, application design, and operational practice.
Can Foundry replace Gotham?
Foundry can reproduce many underlying data, Ontology, analytics, and application responsibilities. It does not automatically reproduce every specialized Gotham mission application or interaction pattern. Replacement requires a workflow-by-workflow inventory, including geospatial, graph, media, planning, edge, audit, and interoperability needs.
Get Started with Theresa for FREEConclusion
The most accurate Palantir Gotham vs Foundry comparison is mission application suite versus foundational data and operations platform. Gotham gives analysts and operators specialized tools for multimodal intelligence, live situational awareness, investigation, planning, and mission coordination. Foundry gives organizations the services to integrate data, define an Ontology, author logic, build analytics and applications, connect AI, and govern actions.
They can be alternatives for a narrowly defined workflow, but they are increasingly complementary at the architecture level. Foundry can manage shared objects and controls; Gotham can provide mission-specific interaction surfaces; AIP can add agents and models; Apollo can deliver the software across connected and disconnected environments.
Evaluate the products with one end-to-end workflow. Start from an authoritative event, trace the data and security markings, identify the object in each application, execute an approved action, reconcile the downstream result, and test the same process during degraded connectivity. Measure decision time, data freshness, access-control behavior, operator adoption, recovery, and total cost.
For alternative enterprise platforms, read our Palantir alternatives comparison. To compare the Palantir platform with a lakehouse architecture, see Databricks vs Palantir. To explore an agent-first approach to operational workflows, learn about AI Theresa.





