Queuebase vs Trigger.dev
Overview
Queuebase is a background job processing system built for Next.js that uses a callback model — jobs are defined in your app, and the Queuebase service calls back to your existing infrastructure to execute them. It offers a tRPC-style, fully type-safe TypeScript API with Zod validation and prioritizes simplicity and developer experience.
Trigger.dev is a managed background job platform that runs your tasks on its own cloud infrastructure (or self-hosted via Docker/Kubernetes). It uses a checkpoint-resume system to support long-running, durable execution without timeouts, and provides scheduling, concurrency controls, waitpoints, and multi-framework support.
Architecture Comparison
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 | Coming soon |
| 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.