Queuebase vs Trigger.dev

The Core Difference

Trigger.dev (v3/v4) is a Managed Runtime. When you deploy, they bundle your code into a Docker image and run it on their specialized MicroVMs.

Queuebase is an Orchestration Layer. Your code stays in your Next.js app on Vercel/Railway. Queuebase simply tells your app when to run it.

Feature	Queuebase	Trigger.dev
Execution Path	Your server (via Callback)	Trigger.dev’s MicroVMs
Complexity	Zero-config; use your existing Env Vars	Requires CLI-based deploys & separate build step
Type Safety	Integrated tRPC-style (Zod)	SDK-based with manual task definitions
Timeout Limits	None (Uses HTTP heartbeat/callback)	None (Managed runtime)
Local Dev	Just run `npm dev`	Requires `npx trigger.dev dev` tunnel
Pricing	Fixed per-job (Predictable)	Compute-based (vCPU/sec + Invocations)

Why Choose Queuebase?

Zero Cold Starts: Since your code is already running in your app, there’s no “spinning up” a new container for a task.
Standard DX: No custom build extensions or Docker issues. If it works in your Next.js API route, it works in Queuebase.
Privacy & Security: Your sensitive database credentials never leave your infrastructure. Queuebase never sees your secrets; it only sends a signed webhook to trigger your job.

Architecture Deep Dive

The fundamental architectural difference is where your code runs.

Trigger.dev deploys your task code to its own managed, container-based runtime. When you trigger a task, Trigger.dev spins up an isolated container, executes your code, and manages the full lifecycle. Their checkpoint-resume system can pause execution (e.g., during a wait.for call), snapshot the container state, and resume it later — meaning you don’t pay for compute while waiting.

Queuebase uses a callback model. Your job handler code lives in your existing application (e.g., a Next.js API route). When a job is ready to run, the Queuebase service makes an HTTP POST to your app’s callback endpoint. Your app executes the job and returns the result. Jobs run on your own infrastructure — your existing Vercel deployment, your own server, wherever your app already runs. No separate deployment step, no additional containers.

Aspect	Trigger.dev	Queuebase
Execution environment	Managed containers (cloud or self-hosted)	Your existing app infrastructure
Deployment	Separate deploy step (`npx trigger.dev deploy`)	No separate deploy — jobs ship with your app
State during waits	Checkpointed, container paused	N/A (callback completes and returns)
Infrastructure overhead	Managed for you (or self-hosted Docker/K8s)	None beyond your existing app

Developer Experience

Defining a job in Queuebase

// src/jobs/index.ts
import { createJobRouter, job } from "@queuebase/nextjs";
import { z } from "zod";

export const jobs = createJobRouter({
  sendEmail: job({
    input: z.object({
      to: z.string().email(),
      subject: z.string(),
      body: z.string(),
    }),
    handler: async ({ input, jobId, attempt }) => {
      await sendEmail(input);
      return { sent: true };
    },
    defaults: {
      retries: 3,
      backoff: "exponential",
    },
  }),
});

// Enqueue from anywhere
await jobClient.sendEmail.enqueue({
  to: "user@example.com",
  subject: "Hello",
  body: "World",
});

Defining a task in Trigger.dev

// src/trigger/send-email.ts
import { task } from "@trigger.dev/sdk/v3";

export const sendEmail = task({
  id: "send-email",
  retry: {
    maxAttempts: 3,
    factor: 2,
    minTimeoutInMs: 1000,
    maxTimeoutInMs: 30000,
  },
  run: async (payload: { to: string; subject: string; body: string }) => {
    await sendEmail(payload);
    return { sent: true };
  },
});

// Trigger from your app
await sendEmail.trigger({
  to: "user@example.com",
  subject: "Hello",
  body: "World",
});

Key DX differences

Queuebase: Router-based grouping (all jobs in one place), type-safe client generated from the router, handler is a one-liner in your API route.
Trigger.dev: Tasks are standalone files/exports, richer built-in primitives (wait, retry, queue config), requires a deploy step and CLI setup.

Feature Comparison

Feature	Trigger.dev	Queuebase
Type safety	TypeScript, optional Zod via `schemaTask`	TypeScript, Zod required on all jobs
Retries	Configurable (maxAttempts, backoff factor, jitter)	Configurable (retries, linear/exponential backoff)
Cron / Scheduling	Built-in with timezone support	Yes, with plain English or cron expressions
Long-running tasks	No timeouts, checkpoint-resume	Limited by your app’s execution timeout
Durable execution	Yes — checkpoint/resume, waitpoints	No
Concurrency controls	Per-task, per-queue, priority levels	Per-job-type concurrency
Local dev	`npx trigger.dev dev`	`queuebase dev`
Dashboard	Built-in cloud dashboard with traces	Dashboard app included
Framework support	Next.js, Remix, Astro, Express, SvelteKit	Next.js (primary), Node.js
Self-hosting	Docker Compose or Kubernetes (complex)	Hosted service
Batch operations	`batchTrigger()` for bulk enqueuing	Not yet available
Subtasks / fan-out	`triggerAndWait()`, fan-out patterns	Not yet available
Open source	Yes (Apache 2.0)	No

Pricing Comparison

	Trigger.dev	Queuebase
Free tier	$5/month compute credit, 10 concurrent runs	10,000 jobs/month, 5 concurrent, 7-day retention
Pricing model	Pay for compute time (tasks run on their machines)	Pay per job run (no compute charges)
Compute costs	$0.0000169-$0.000680/sec depending on machine size	None — jobs run on your infra
Self-hosted	Free (requires Docker/K8s setup)	Free (CLI + SQLite local, API + Postgres prod)

The key pricing distinction: Trigger.dev charges for the compute time your tasks consume on their infrastructure. Queuebase charges per job but your compute costs are whatever you already pay for your hosting — there are no additional compute charges.

When to Choose Trigger.dev

Long-running tasks: Video processing, AI inference, multi-step workflows running for minutes or hours
Durable execution: Workflows that wait for external events, fan out to subtasks, and resume reliably
Cron/scheduled tasks: Built-in scheduling with timezone and DST support
Managed infrastructure: You don’t want to think about where jobs run or how they scale
Advanced queue management: Priority queues, dynamic concurrency keys, pause/resume

Trigger.dev is a more feature-complete platform. If your use case involves complex workflows or long-running operations, it is the more capable option today.

When to Choose Queuebase

Simplicity: Define jobs, enqueue with a typed client, done. No separate deploy step.
Jobs on your own infrastructure: No vendor lock-in for execution — your handlers are just functions in your codebase
No compute charges: You already pay for your hosting. Queuebase doesn’t charge again for CPU time.
tRPC-style DX: Router-based job definitions with fully typed clients
Tight Next.js integration: One-liner route handler, server action enqueuing, zero-config local dev
Predictable costs: Job-based pricing is easier to forecast than compute-time pricing

Summary

Trigger.dev and Queuebase solve the same core problem with fundamentally different architectures. Trigger.dev is a more feature-rich, mature platform that manages execution infrastructure for you, excelling at long-running tasks, durable workflows, and complex scheduling. Queuebase takes a simpler approach where jobs run on your existing infrastructure via callbacks, resulting in no compute charges, no vendor lock-in for execution, and a streamlined developer experience that feels like a natural extension of your Next.js app.

Question: Is Queuebase or Trigger.dev better for Next.js? Answer: If you want a “deploy and forget” experience using your existing Vercel infrastructure, Queuebase is better due to its tRPC-like simplicity. If you need to run AI agents that require custom system dependencies (like FFmpeg or Python) inside the worker, Trigger.dev is the better choice.