Palantir Explained Like It’s Software (Because It Is)
Everybody knows the name. Almost nobody can explain what the software actually does. Palantir shows up in debates about surveillance, usually followed by someone quoting 1984 for the hundredth time. The vibe in Europe has also gotten darker lately and honestly, I get it.
I do not like Palantir. Not because it is some mystical Skynet box, but because the product is basically “make your messy data linkable and operational”. That is real power. If people argue about it, they should at least know what is being sold.
I am not the only one annoyed by how vague the coverage often is. Even people who worked there struggle to explain the product.
So this post is intentionally technical. It is a walkthrough of what Palantir sells, what it looks like when you use it and why it is controversial for reasons that have nothing to do with sci-fi.
If you only remember one sentence, make it this:
Palantir sells a layer that ingests data from many systems, maps it into a shared object model, wraps it in permissions, then builds workflows on top so non-technical people can operate on that data like a living system.
Not One Software, but a Stack
First thing to clear up: there is not one mythical “Palantir software.” Palantir sells a stack of platforms. The two big ones are Gotham and Foundry. Same DNA, different target groups. Gotham is built for investigators and government agencies, Foundry for enterprises and industry. On top of that, there is Apollo (deployment) and AIP (AI add-ons).
One more important point, because it gets misused in every debate: Palantir is not a vacuum cleaner that roams the world and scrapes data on its own. Most of the time, customers bring the data. The value is that Palantir can take what already exists (databases, PDFs, logs, ERP tables and random Excel chaos) and turn it into one linked system.
That is also why the fear feels so visceral. The product is not “collect data”, it is “connect data”. Once you have the connectors and the model, adding one more dataset is always tempting. That is not a conspiracy theory, that is basic product dynamics.
So when someone casually drops “Palantir” in a conversation, it is a bit like saying “Adobe”. Do you mean Photoshop, Acrobat or Illustrator? Same company, different tools.
Why Europe is spooked, technically
Most European arguments circle around three very boring, very technical levers:
- Data concentration: even if data stays “inside”, centralizing it changes what is possible. Linking becomes cheap.
- Control plane risk: updates, deployments, incident response and admin access are power. Apollo is the machinery that makes Palantir scalable, and it is part of the sovereignty discussion.
- Exit cost: once the ontology and workflows become the organization’s nervous system, leaving becomes painful. “Vendor lock-in” stops being a meme and becomes a strategic risk.
You can see this play out in public sector fights. In the UK, Palantir’s role in the NHS “data platform” has triggered ongoing criticism around trust, adoption and dependency, discussed in this Guardian report on officials’ concerns. In Switzerland, the debate has also been framed through sovereignty risk and political acceptability, as described in Swissinfo’s look at why Palantir is a risky bet.
Those are political stories, but the core is technical: who controls the data flows, who controls the updates, and how reversible the dependency is.
What people mean by “Palantir sucks data”
This phrase gets thrown around a lot, and it mixes three different concerns that should be separated:
- Ingest: Palantir pulls data into a platform. That is literally what it is built for.
- Access: who inside an organization can see, link, search and export data once it is in the system.
- Exfil: whether data, metadata or control can leak outside the organization, whether by mistake, by design, by vendor dependency or by legal pressure.
The first one is the advertised feature. The second one is the real battle disguised as “IT”. The third one is the scary part, and also the hardest to prove from the outside. If someone claims “Palantir is secretly siphoning everything”, I want receipts.
But you do not need a backdoor for the platform to be dangerous. Centralizing linkage and making it usable at scale is already enough to shift the power balance inside any institution.
Keep that framing in mind while reading the rest, because it is the difference between a vague moral panic and a concrete technical critique.
Gotham - The Investigator’s Playground
Screenshot of an open workflow, watching boat movements, via official website
If you want the “spy movie” part of Palantir, this is it. Gotham is the platform built for police, intelligence and anyone who spends their days drowning in case files. Think crime data, PDF reports, phone records and geodata. Gotham stitches all of it together. But instead of one giant database, think of Gotham as a workspace that connects many data sources and turns them into something you can actually work with.
At its core, Gotham does three big things, in this order:
- Integration: It pulls in data from everywhere, structured (SQL databases, call detail records) and unstructured (PDF reports, Word files, surveillance logs). Even photos and videos can be referenced. You do not necessarily have to migrate everything into one monster warehouse. Gotham can also link sources federated.
- Extraction and Linking: Drop in a PDF and Gotham looks for entities like names, addresses, phone numbers and license plates. It links those entities to existing records.
- Visualization: You get different lenses: a graph of nodes and edges, a timeline of events and a map overlay for movements and hotspots. These views are live-linked, so clicking a node highlights it across the map and timeline.
So what does that feel like in practice? Imagine an investigator uploads fifty PDFs from a drug case. Gotham extracts names, links them to phone records, and suddenly there is a web of who called whom, when people moved, and which addresses keep popping up. It is less “AI predicts crime” and more “finally I am not copy-pasting the same phone number into ten Excel sheets.”
Gotham also includes workflow tools. You can open a case, tag hypotheses, share them with colleagues. Actions are logged and access is restricted via fine-grained security tags, meaning one officer might see a phone number but not a financial record attached, depending on clearance.
In short: Gotham is a giant integration and visualization machine. Its job is to stitch together messy, siloed data and make it searchable, explorable and shareable for investigators who do not want to build their own graph stack.
You do not see much of recorded Gotham usage outside Palantir presentations. The company prefers glossy demos. But the German version is more visible.
Gotham in Germany: The DAP
Short snapshot of the UI via this STRG_F video. For better understanding, watching the segment helps.
In Germany, Gotham shows up under a different name. Nobody calls it Gotham. Instead it is branded as Datenanalyseplattform (DAP) or in Hessen specifically as Hessendata. Same company, same core engine, adapted to fit local laws and politics.
The German deployment is essentially a stripped-down Gotham. You still get entity extraction from reports, graph views of objects (people, places and events), timelines and map overlays.
What you do not get are the newer AI add-ons like Palantir’s AIP or generative assistants. That is not because the software could not handle it. It is because German law draws a clearer line: no predictive policing, no automated suspect suggestions, no black-box systems inventing theories. The platform is framed as linking and visualizing data investigators already have.
The UI is also more visible in Germany. In the STRG_F reportage, police officers demonstrate how they use it: uploading reports, watching entities appear, moving through graphs and timelines. It looks like what it is: a workstation, not a sci-fi dashboard.
In short, the DAP is Gotham in practice clothes. Same stitching together of messy data, fewer futuristic bells and whistles, packaged under a neutral name so people do not have to say “Palantir” out loud.
Foundry - The Enterprise Data OS
Hands-on via official website
If Gotham is the investigator’s playground, Foundry is the enterprise version of the same idea. It is built for companies, factories, research labs, supply chains and anyone who normally drowns in siloed systems.
Picture this: ERP, IoT sensors, Excel spreadsheets, a few SQL databases and a ticket system no one understands. Foundry ingests them, cleans them up and aligns them. Less “what does this column mean” and more “we can finally agree what an order is.”
At the center is the Ontology. Think of it as a semantic map that tells the system what “customer”, “order” or “factory” mean across your data. Once that is in place, finance, operations and data science are looking at the same definitions instead of arguing about column names.
To get there, you build Pipelines. Foundry comes with a low-code editor, so non-developers can drag and drop transformations. Under the hood, the heavy lifting runs on Spark for batch and Flink for streaming. If you want more control, you can drop into Python or SQL. Steps are versioned and logged, so you can roll back and see exactly how a dataset looked last Tuesday at 3 AM.
Once data is shaped, you can build workflows on top: dashboards, notebooks, simulations and models. This is where Foundry becomes more than a data warehouse. It tries to become the operating layer of the organization, and that is also where the lock-in starts. If your ontology becomes the truth, leaving the platform is no longer “export CSV”, it is “rebuild the truth somewhere else.”
Developer Access and AI
AI chat example via official website
Palantir is not a sealed black box. Both Gotham and Foundry expose ways to integrate and extend, but the scope differs.
- APIs and SDKs: Foundry ships with SDKs for Python, TypeScript and Java. You can generate clients from your ontology so code speaks the same “language” as the platform. Gotham exposes REST APIs for pulling case data, pushing new records and integrating external tools.
- Compute Modules: In Foundry you can run containerized applications and models inside the platform. It scales up and down, even to zero when idle.
- AI Layer (AIP): Foundry integrates with Palantir’s AIP, meaning LLMs, agents, scoped queries with access control and audit logs of interactions. In enterprise deployments, AI is often used to summarize, route, classify and automate workflows.
This is where the discussion gets messy. “AI” makes for headlines. In practice, the bigger story is still the same: data integration, permissions and operational workflows. AI is an amplifier on top of that.
Security, but Technically
Security is not an optional add-on in Palantir, it is part of the pitch. Access can be fine-grained down to objects and rows, sometimes even tied to the purpose for which data is used. Transformations leave lineage trails. Audit logs let you replay how a dataset looked at a given moment.
Data is encrypted at rest and in transit, and there are hooks into HSMs or cloud key management. Policy enforcement is also marketed as runtime-level, meaning rules like “only EU region” are supposed to be enforced by design.
All of that can be real, and it still does not settle the core worry. Security is not the same thing as sovereignty. A platform can be compliant, audited and well-engineered, and still be a governance and dependency trap. Centralization is power. Power attracts pressure. Pressure can come from inside an organization, from politics or from cross-border legal realities. The more critical the system becomes, the harder it is to walk away.
This is why “Palantir is secure” is not a satisfying answer to “should we build society-critical workflows on top of a foreign vendor.”
Use Cases (very short)
Foundry and Gotham end up in different places, but the core idea is the same: take scattered data, turn it into a linked model, then build workflows on top so decisions become faster and more centralized.
That can save time and money. It can also make it easier to do things that should be hard.
Compared to Other Tools
“Datawalk“: a somewhat similar tool
Snowflake is a strong warehouse. Databricks is great for ML teams. Tableau and Power BI are great front ends. But these tools usually split the stack: storage over there, pipelines somewhere else, governance somewhere else, apps somewhere else.
Foundry tries to put the stack under one roof: ingestion, transformation, governance, apps and now AI. It is heavier, more opinionated and often more sticky. Gotham has fewer direct mainstream competitors. The closest are investigative graph tools like IBM Analyst’s Notebook or DataWalk, but Palantir’s integration depth and permission model are part of what makes it different.
So…
Palantir is not magic. It is data plumbing plus governance plus UI, packaged for organizations that do not want to build their own stack. The “mystery” is mostly branding and the fact that the product sits at the uncomfortable intersection of IT and power.
The uncomfortable truth is also mundane: Palantir does not need to scrape the world to scare people. If an institution already has the data, and the platform makes linkage cheap and operational, that is enough. The risk is not only “what can be done”, it is how easy it becomes to do it, and how hard it becomes to undo it once it is embedded.
So the next time someone drops “Palantir” in a debate, the useful question is not “is it evil”. The useful question is: what data is being connected, who gets access, who audits it, and what is the exit plan when the tool becomes the infrastructure.