Inngest vs LlamaIndex: Why the Comparison Is the Wrong Question

Hokai diagram of the two layers: LlamaIndex writes the agent's steps, Inngest checkpoints each one so a crash does not lose the work. Source: Inngest and LlamaIndex docs, checked 7 November 2026.

Search for Inngest and LlamaIndex together and you will not find a head-to-head, because the two tools sit on different layers of an AI application. LlamaIndex is the Python framework that decides what an agent does: retrieve this, call that tool, build the answer. Inngest is the service that runs those steps so a crash, a timeout or a two-day wait for a human approval does not lose the work. Both names turn up in the same searches about durable agents, and that overlap is the reason this guide exists.

What moved since August is the overlap itself. LlamaIndex now ships a plugin that makes its workflows durable, which the August version of this guide said did not exist. Three questions settle the choice now: does a run have to outlive the process that started it, who operates the database that remembers it, and how many steps does a typical run take.

What changed since 14 August 2026

The August version of this guide got three things wrong or out of date, and the rest of this page is rebuilt around the corrections.

Re-checked on 7 November: the central split holds. LlamaIndex defines the agent and Inngest runs it. What no longer holds is the claim that choosing durability means choosing Inngest.

Which layer each one owns, and where they now overlap

Keep LlamaIndex for the agent logic: retrieval, tool calls, the pipeline that turns a document into an answer. Nothing in Inngest helps you chunk a 200-page PDF or decide which retrieved passages answer the question. Its open-source framework had about 52,800 GitHub stars when we read the repository on 7 November.

Durability is where the two now meet. A LlamaIndex Workflow can be made crash-safe three ways, and each one asks something different of your team:

1. Manual snapshots. LlamaIndex's own documentation says workflows are ephemeral by default and that the Context.to_dict() pattern survives a restart but not a crash mid-run. To survive a crash you snapshot as the run progresses and resume from the last snapshot.
2. The llama-agents-dbos plugin. Per LlamaIndex's DBOS page, it persists every step transition automatically, with SQLite by default and Postgres for multi-replica deployments. The same page shows a run killed at tick 8 resuming at tick 8 when called again with the same run ID.
3. Inngest underneath. Wrap the steps as Inngest steps and Inngest stores each result as a checkpoint, so a retry repeats only the step that failed.

What the DBOS plugin changes

The second route is what changed. It is a LlamaIndex-documented way to get automatic persistence without a second hosted vendor, and the guide's August verdict did not account for it.

What the manual route asks you to build

Teams often pick the snapshot pattern because it is free, then discover what it asks of them. LlamaIndex's durable-workflows page walks through the work, and it is the best argument for either the plugin or Inngest.

• Choose where snapshots live. Context.to_dict() gives you the state; writing it to a database, and reading it back, is your code.
• Choose when to snapshot. The docs suggest watching the event stream and writing when a step finishes, and throttling the writes in a busy run, since each snapshot is a serialise and a write. A crash then costs you at most the interval you chose.
• Keep heavy inputs out of the snapshot. The docs say large inputs should come from a Resource, which is re-created on resume instead of serialised into the state.
• Make every step safe to run twice. A step that was mid-execution when the process died runs again from the top on resume.

None of this is hard for one workflow. It is a tax that every workflow repeats, and it is the same tax the plugin and the hosted service both exist to remove. When we weigh LlamaIndex against Inngest for a production agent, the honest question is how many workflows you will write before you resent paying that tax by hand.

What each one costs

Inngest bills in executions and LlamaIndex bills in credits, so the two price lists cannot be laid side by side without translating. This table lists every public plan as read on 7 November 2026.

The open-source LlamaIndex framework stays free. What LlamaIndex charges for is LlamaParse, its commercial document platform, which its pricing page says is not open source. The Pro plan also carries a limited-time bonus of 800k credits, one-time, for business email domains only, and the pricing page says unused bonus credits expire immediately on a downgrade.

What the same job costs on each

The meters measure different things, so compare them on a job instead. Inngest's pricing FAQ says an execution is metered per function run and per step inside it, so a function with five step.run() calls uses six executions. The arithmetic below is ours, built from the pricing page.

A page costs one credit only in basic parsing; the pricing FAQ says layout-aware agentic parsing costs more per page, so the 10,000-page figure is a ceiling, not a forecast.

The step count matters more than the table suggests. An agent that loops twelve times through a model call and a tool call, with each pass wrapped as a step, uses thirteen executions. At that size Pro's included million covers about 76,900 runs, and the free allowance covers about 3,800. Past the included amount, Inngest charges per execution, so a chatty agent costs more than a terse one even when both answer the same question.

LlamaIndex workflows have no per-step meter at all, because the framework runs in your process; what you pay there is the credit cost of parsing and indexing, plus whatever your own database costs.

• Free5
• Pro100
• Business500 Leader

Read from Inngest's pricing page.

Concurrency is the limit an agent hits first. Free allows 5 steps running at once, Pro includes 100 and Business includes 500, and Pro can buy more at $25 for each extra 25. A fan-out that calls a model on thirty documents at the same moment is therefore queued on Free and runs freely on Pro.

Neither bill is the real cost for a small team. A four-person group building a document agent will likely sit inside both free allowances for months. The expense that arrives first is engineering time, which the next section is about.

Who owns crash recovery

Inngest's durable-execution docs describe the model plainly. After a step succeeds, its result is stored as a checkpoint and the handler keeps going; if the run waits or a later step fails, saved results for completed steps are used without running their callbacks again. A wait does not hold a worker, and your compute pauses completely while the run sleeps. The docs also state that functions run on your current infrastructure, through its Serve (serverless) or Connect (workers) options, with no separate cluster to run.

The wait length is a plan limit. Maximum run length is 30 days on Free, 90 on Pro and 366 on Business, per the comparison table on the pricing page. A support agent that parks a ticket for a customer's reply fits inside the Free limit.

The DBOS route works differently. Per LlamaIndex's page, a workflow and all of its steps run in the same process, a replica owns every workflow it starts, and individual steps are not spread across replicas. That is convenient, because steps can rely on local files and in-memory caches. It also means the unit of scaling is the workflow, not the step. For multi-replica production the docs point to Postgres and, optionally, DBOS Conductor for auto-scaling and monitoring dashboards.

A durable run, step by step

This is a hypothetical support-ticket agent, not a customer case. It shows where each tool does its part when the logic lives in LlamaIndex and the execution layer is Inngest.

The point of the timeline is the third row. If the model call fails, only that step repeats, because the retrieval result is already saved. On Inngest's meter this run uses four executions: one for the run and one for each of the three steps. The approval row is a design question as much as a technical one, and our guide to approval gates covers when an agent should stop and ask. The last row needs a mail provider, which our roundup of email APIs for agents compares.

Where Inngest wins

• A mixed stack. Inngest's GitHub organisation carries SDK repositories for JavaScript, Python, Go and Kotlin, and the Python package inngest is at 0.5.20 with a Production/Stable classifier, released 2 November 2026. A Python LlamaIndex service and a TypeScript API can share one execution layer.
• Long waits without a held process. The run sleeps on Inngest's side and resumes on your compute.
• Flow control and tracing included. Concurrency, priority, throttling, debounce and rate limiting are built in, and trace history runs 24 hours on Free, 7 days on Pro and 14 days on Business.
• Nothing to host. The cloud product needs no queue and no worker fleet of your own, and the project can also be self-hosted as a single binary with SQLite or Postgres, per its docs.
• Active product. The Inngest changelog shows Durable Endpoints on 10 February 2026 and Sandboxes, isolated microVMs callable from any function, on 6 October 2026.

Where LlamaIndex wins

• Everything upstream of execution. Parsing, chunking, OCR on a scanned contract and retrieval quality are LlamaIndex's job, and its LlamaParse platform is built for them.
• One fewer vendor. With the DBOS plugin, durability comes from a database you already run. The manual snapshot pattern costs nothing at all and is enough for an internal tool where a lost run is an annoyance.
• Metering that fits document work. A credit meter follows the work done on pages, while Inngest's execution meter follows steps, so the bill for an agent loop grows with every step it takes.
• Existing orchestration. A team already on Temporal or its own queue can run LlamaIndex Workflows on top without adding Inngest.

Data handling, security and compliance

The two vendors handle your data in very different places, and that often decides the choice for a regulated team.

• Inngest. Its security page says it is SOC 2 Type II compliant, that all data sits in encrypted AWS databases in the United States, and that traffic uses TLS only. A signed data processing agreement is offered on paid plans. On the pricing page, HIPAA is an add-on on Pro and Business and included on Enterprise, while SAML, RBAC and audit trails are Enterprise features.
• LlamaParse. Its pricing page lists SOC 2 Type II, GDPR and HIPAA certification, and says enterprises can deploy in a private VPC on any cloud provider. It is also sold through the AWS and Microsoft Azure marketplaces.
• The open-source framework and the DBOS plugin. Run state lives in your own SQLite or Postgres, so nothing leaves your infrastructure unless your own steps send it.

If a compliance reviewer needs data to stay inside your own network, the DBOS route and self-hosted Inngest are the two that can do it.

Who should pick which

• A Python-only agent, one Postgres, few replicas: LlamaIndex with the DBOS plugin. Try it before adding a vendor.
• A mixed TypeScript and Python stack, or serverless deployment: Inngest, because one execution layer serves both languages.
• Human approvals that wait days: Inngest, where a wait does not hold a process, or DBOS if you already run Postgres and accept the same-process model.
• A weekend prototype: neither. Use plain LlamaIndex and the manual snapshot pattern.
• A team that needs help choosing: answer a few questions in Smart Match and get a shortlist matched to your use.

Other options worth a look

The same job has more candidates than these two.

• DBOS itself. The runtime behind the LlamaIndex plugin is a product of its own, and it does not have a Hokai record yet, so it is queued for one rather than linked.
• Temporal. Per Inngest's own durable-workflows docs, Temporal runs as a server cluster, self-hosted or on Temporal Cloud, with separate worker processes. That page is written by a competitor, so treat the contrast as Inngest's framing. See the Temporal record for the other side.
• Trigger.dev. A different background-jobs platform; read Trigger.dev vs Inngest for that head-to-head.
• LangGraph. If you are choosing an agent framework rather than adding durability to one, LangGraph and LangChain are the usual neighbours of LlamaIndex, and CrewAI covers multi-agent teams.
• Visual builders. n8n, Zapier and Make replace developer-written steps entirely, which is a bigger rewrite than layering durability under existing code. Our roundup of agent builders compares them, and the workflow automation directory lists the rest.
• Same category. Mastra also sits under AI orchestration on Hokai, and is worth a look if neither framework fits.

The whole category is listed under AI orchestration tools, and best agentic AI in 2026 covers the agents that sit on top.

The strongest objection

The obvious objection is that the DBOS plugin makes Inngest unnecessary for a LlamaIndex team. For some teams it does. The plugin is at 0.7.0, which signals a young interface, and the first release was in February 2026. Its model keeps a whole workflow in one process, so a single very long workflow cannot be spread across machines the way separate Inngest steps can.

The answer to that is not "always add Inngest". It is: start with the cheapest option that survives your actual failure, which for a Python team with Postgres is now the plugin, and move to Inngest when the stack, the replica count or the observability needs outgrow it. Inngest is also a second vendor and a second bill, and at 50,000 executions most early agents will not leave the free plan for a long time.

Switching or layering

There is no official package that joins the two, so layering is a pattern you build. In practice it means wrapping the steps already inside a LlamaIndex Workflow as Inngest step.run() calls, so Inngest owns retries and persistence while LlamaIndex's step and event model still defines what each call does. Inngest's pricing page describes this as wrapping existing code, with no refactoring of the business logic.

Moving from manual snapshots to the DBOS plugin is smaller: the docs say the workflow code itself has nothing DBOS-specific in it, and you pass a DBOSRuntime when you construct the workflow. Good context hygiene helps either way; our explainer on context engineering covers what belongs in the state you persist.

Sponsor spot open

What would change the call

Three developments would move the recommendation, and each is worth re-checking.

• A version 1.0 of the DBOS plugin, or LlamaIndex shipping a hosted execution layer of its own. Either would make the "add Inngest underneath" pattern a second choice for most Python teams.
• A change to Inngest's metering. Its 7 November FAQ counts every step as an execution; a move back to counting runs would cut the cost of long agent loops.
• A native LlamaIndex integration for Inngest. None exists today.

Funding does not settle any of this, but it shows both companies are staying in the market. Inngest announced a Series A led by Altimeter in September 2025, and LlamaIndex announced a Series A led by Norwest Venture Partners alongside the general availability of its cloud product. Re-read the plugin's release page first the next time this guide is reviewed, because that is where the verdict is most likely to move.

Frequently asked questions

Are Inngest and LlamaIndex competitors?

Mostly no. LlamaIndex is a Python framework that defines retrieval and agent logic, while Inngest is a service that runs steps durably. They overlap only on durability, since LlamaIndex now documents a DBOS plugin that persists each workflow step automatically.

How does Inngest count an execution?

Inngest meters one execution for the function run plus one for each step inside it, so a function with five step.run calls uses six executions. At that size the 50,000 free executions cover about 8,300 runs a month, and Pro's 1 million cover about 166,000.

Does a LlamaIndex Workflow survive a crash on its own?

Not by default. LlamaIndex's documentation says workflows are ephemeral, and the manual Context snapshot pattern survives a restart but not a crash mid-run unless you snapshot as it progresses. The llama-agents-dbos plugin, at version 0.7.0, persists every step transition automatically.

What does LlamaIndex cost compared with Inngest?

The open-source LlamaIndex framework is free. Its LlamaParse platform has pay-as-you-go at $1.50 per 1,000 credits after 10,000 free ones, and Pro at $500 a month. Inngest is free to 50,000 executions, with Pro from $99 and Business from $499 a month.

When should a team skip Inngest?

Skip it for a prototype nobody outside the team uses, or when you run one Python service with a Postgres database and can use the DBOS plugin instead. Skip it as well if Temporal or another orchestration layer already runs your durable work.

Covered in this guide

• Inngest: Inngest runs event-driven background jobs and AI workflows with no queue or worker fleet to manage. A Free plan that needs no credit card covers development and small production apps.
• LlamaIndex: The world's most accurate agentic OCR and document-specific AI workflows for enterprise automation
• CrewAI: Open-source Python framework for multi-agent AI, MIT-licensed with about 59.6K GitHub stars, plus the CrewAI AMP platform for building and governing agents.
• LangGraph: MIT-licensed Python framework for stateful, multi-step AI agents built as graphs, with human-in-the-loop approvals. Library is free; hosted option is paid.
• Make: No-code visual automation platform to connect apps and build AI workflows at scale
• Mastra: Open-source TypeScript framework for building AI agents and workflows, routing to 90+ model providers through one interface.
• Temporal: Open source (MIT) durable execution platform for resilient workflows as code. Self-host free, or use Temporal Cloud with pay-as-you-go pricing and no base fee.
• Trigger.dev: Open-source TypeScript platform for durable background jobs and AI agents. Checkpoint-resume execution survives crashes and redeploys, auto-retries, real-time traces. Free tier available.

Sources