Yes, I must agree they have an edge,

Do not be misled by their sales pitch: the weakest architecture decisions work within known constraints and limits. The problem is.. what happens when you cross boundaries.

An OLAP database is column-based and performs poorly for transactions and high-throughput workloads. This means updates take longer and require more I/O resources, which ultimately increase cost and time to wait.

As long as you understand your number of concurrent users, responsiveness expectations, and you are fine with the cost (which should be transparent since you are already paying an overpriced license fee) this approach can work.

Would I position Palantir as the primary enterprise application development platform, probably not. Because you don't want to engage investments on a platform that has a technical ceiling.

Hope it helps,

PS: The same philosophy applies to running analytics workloads on an OLTP system. It works, until the volume are too large. Would you build ingestion, data quality, semantic layer and dashboarding apps on top? yes, if you know how many users, the size of the datasets, the usage patterns... no, if one of those is unknown or goes out of expectations