Palantir for the Rest of Us
Why we stopped pitching Inferal as a database and started pitching it as operational intelligence.
Lately, when someone at an event asks what Inferal is, I open with one line:
“We’re Palantir for the rest of us.”
Either people light up, or they laugh. Both reactions are an opening.
The line earns its keep because the directional comparison is real. Palantir is, for most people in the room, the closest reference point they have for software that lives next to operational data and acts on it: that anchor is doing a lot of work. The “for the rest of us” carries the rest of the meaning: who can deploy it, who can afford to run it, who it’s for. The conversations that follow have been clarifying enough that they’re worth writing down.
Databases Sit on Everything and Do Nothing
Look at where databases sit in any organization. They have all the relevant context, in real time, about what is happening. Customers signing in. Transactions clearing. Tickets closing. Replication slots lagging. Replicas catching up. Carts abandoned. Devices changing.
And what does the database do about any of it?
Nothing.
“I am just a storage, man.”
Whatever inference, decision, or action the business wants to take based on that data has to happen somewhere else. So we build that “somewhere else”: backends, job queues, durable workflow engines, event buses, observability pipelines, agent runtimes. Each new layer exists because the layer below it refused to take a position on the data passing through it.
We’ve collectively spent two decades layering software on top of databases that already know everything but say nothing. Our systems aren’t getting simpler.
AI-assisted development is now multiplying the rate at which systems get written, refactored, and replaced. The failure modes of layered architectures don’t change with that. They just arrive much earlier in a system’s life than they used to.
And the pattern of large outages has shifted. Used to be a misconfiguration, a power failure, something specific that broke. Increasingly, nothing breaks. Systems work exactly as designed, and the failure is in how they interact when no one is reasoning about them as a whole.
From Queries to Standing Orders
Inferal interacts with data differently. Instead of queries, you write rules: standing orders that declare what new data the system should infer when conditions hold. The data layer watches for the conditions, materializes the inferences, and triggers whatever the rule says to do next.
A few examples that have landed well in conversation:
SaaS. For every user who has not used the product in over 30 days, infer a “user at risk of churn” object. A rule reaches out and tries to re-engage them.
Database operations. For every Postgres replication slot lagging past a threshold, infer a “degraded replica” object. A rule pages the right on-call.
Fintech. For every card transaction above a threshold, from a new device, shortly after a password change, infer a “suspected account takeover” object. A rule triggers step-up authentication.
No queries. No glue code. No “go check this every five minutes.” You declare what you want the system to know, and the system figures out when to know it.
And every rule activation leaves a trace. The rule that fired, the input data that caused it to fire, the inferred output. You can answer “why did this happen” by reading rows, not by digging through logs across seven services.
The Three Reactions
The pitch tends to go one of three ways.
“I don’t want my database to do business logic.”
The rarest reaction, and usually the most charged.
These conversations can get combative if I’m not careful. The thesis directly challenges an assumption people have been carrying for their entire careers, which means it’s natural to perceive it as an attack on judgment they’ve already exercised. I try to remember that.
Sometimes there’s a real architectural objection underneath (“we’ve been burned by stored procedures”). Sometimes it’s that the word “database” is doing too much work in the sentence. Inferal is not asking you to put your business logic in PL/pgSQL. It is asking you to put your business logic next to the data that drives it, and to make that logic something the system can reason about: optimize, schedule, audit, parallelize.
But I don’t always get to make that case. Sometimes the conversation is over before it starts, and that’s fine.
“Isn’t this like triggers?”
This response is gold. The person is on the right trajectory and is receptive to learning.
Yes, conceptually it is like triggers. With three differences that matter:
-
Cross-relational conditions. A rule activates on a configuration of data that spans multiple sources, not on a single insert into a single table. The “suspected account takeover” example earlier is not a trigger on
transactions. It is a condition that involves transactions, devices, and authentication events together. -
Speculative execution. Because the system can fork its state, a rule activation can run against a copy of the world: which other rules would fire, what actions would trigger, what new facts would be inferred. You can let the speculation run, inspect the result, and then merge it back into reality or throw it away. A linear transactional database can only commit or roll back. Triggers fire on real state changes; they cannot show you a counterfactual.
-
Whole-program optimization. Because the system has the full rule graph, it can plan evaluation across rules. Pre-compute partial matches that several rules share. Skip evaluation for rules that provably can’t fire given the current state. Decide what to materialize eagerly versus lazily, what to keep hot in memory, and what to leave on cheap storage until a rule actually needs it. Triggers don’t get any of this, because nobody is reasoning about them as a system — each one runs in its own little world.
So yes: triggers, but done right. And built for a workload that nobody seriously tried to support with triggers.
“This could save us a ton of money and frustration.”
This is where it gets interesting. We start digging into the specifics of the systems they already run. Where the latency hides. Which alerts fire on stale assumptions. How many of their batch jobs exist because some upstream system can’t be queried directly. How many on-call pages are really “two systems disagreed about the truth, and now a person has to reconcile them.”
These conversations also help the prospect see where Inferal would actually live in their architecture. Spoiler: it’s usually not “next to” the existing data warehouse. It’s between the operational systems and the people (and agents) who need to act on what those systems are telling them.
When Agents Author Their Own Rules
Here is the bigger thing for 2026.
Rules can activate agents. And agents can author their own rules.
That second half changes the shape of the system. An agent does not need an orchestrator to call it. It does not need a workflow to be embedded in. It becomes a first-class citizen of the data layer, summoned by data and eligible to introduce new behaviors of its own, subject to whatever policies the organization has set.
One prospect gave us a biological analogy that I keep coming back to. Organisms do not have a deterministic, overarching workflow that governs every cell. They respond to conditions, and they adapt continuously to the reality they perceive through the medium they inhabit. There is no central planner. There is a substrate that carries information, and there are responses that fire when the conditions are right.
That is the model we’re building toward. The substrate is data. The responses are rules and the agents those rules activate. The adaptation is agents authoring new rules as the environment shifts.
The Dam, Not the Lake
A substrate has to live somewhere, and most organizations today call that somewhere a data lake. Most of them are not happy with their data lakes.
Inferal has a Relay capability that synchronizes internal and external data sources, including third-party APIs, with very low latency. The first thing a prospect notices is that this looks a lot like a data lake. The second thing they notice is that it doesn’t behave like one.
Data lakes are where data comes to die in the standing water. You collect everything, you defer all decisions about what it means, and you hope someone downstream eventually figures out how to extract value from it. Most of the time, nobody does.
Why do people dam rivers? Often, to generate electricity. The lake that forms behind the dam is incidental. It is not the point of the dam. The point of the dam is the turbines: the structure that converts the potential energy of accumulated water into something the rest of the world can use.
In Inferal, the rules are the turbines. The data piles up only as long as it takes for a rule to spin on it and produce something useful: an inferred fact, a triggered action, a summoned agent. The reservoir is a side effect of having a place to put the turbines.
Operational Intelligence
Someone I talked to recently had the cleanest two-word summary of all of this: operational intelligence.
It captures the thing that “data lake,” “stream processor,” “workflow engine,” and “agent platform” each capture only a piece of. It is intelligence that lives where the operations happen, that activates when the operations need it to, and that does not require the rest of the organization to notice it before it can do its job.
Or, said differently: the difference between systems that execute what was already decided and systems that decide, continuously and from current state across sources, what should happen next.
If any of this resonates and you’d like to see what Inferal looks like applied to a system you actually run, let’s talk.