Installation

BackWave packages, prerequisites, and how to choose between the In-Memory Store and a durable Storage Adapter (Postgres, SQL Server, SQLite).

BackWave is a library you add to an existing .NET application. This page covers the packages, what each one is for, and how to select storage. For an end-to-end walkthrough that gets a job running, start with the Quickstart.

Prerequisites#

• .NET: a supported modern .NET SDK and runtime.
• A database if you want durable storage. BackWave stores its queue in a database you already run via a Storage Adapter, so there is no broker to provision, secure, and monitor. If you don't need durability, the In-Memory Store runs with no database at all.

Packages#

Add the core package plus the host integration. Storage Adapters and the Dashboard are separate packages you add as needed.

# Core + host integration, always needed
dotnet add package BackWave
dotnet add package BackWave.Hosting
 
# Add a Storage Adapter for durable storage
dotnet add package BackWave.Postgres     # Postgres
dotnet add package BackWave.SqlServer    # SQL Server
 
# Optional: the operations dashboard
dotnet add package BackWave.Dashboard
 
# Optional: ride your EF Core transaction for Transactional Enqueue
dotnet add package BackWave.EntityFrameworkCore

The source generator ships inside BackWave. There's no separate analyzer package and no Generator reference to wire up. It emits a payload record, an IJobHandler<T>, the wire format, and BackWave.Generated.BackWaveJobs.Module from your [Job] methods.

Choosing storage#

BackWave implements one Storage Contract; the implementation you select decides durability and deployment shape. Pick by what your deployment needs, not by environment. Postgres is just as valid on your laptop, and the In-Memory Store is a fine fit for a simple single-host service that can tolerate losing in-flight work on a restart.

• In-Memory Store: BackWave.Storage.InMemory.InMemoryJobStore. A first-class implementation that needs no database. It isn't durable (jobs live in process memory and are lost on restart) and it's single-host, so it can't be shared across nodes. Reach for it when zero infrastructure matters more than durability: tests, local dev, and simple single-host deployments. It is also the deterministic store that drives Virtual Time in tests.
• Networked Adapter: PostgresJobStore / SqlServerJobStore. Durable Storage Adapters over a database server reachable across hosts, so a cluster of nodes can span machines.
• Embedded Adapter: a SQLite-backed adapter (durable, single-host). When BackWave's tables live in your own application database file, business writes and job enqueues commit in one file and one transaction, the tightest Transactional Enqueue there is.

Wiring the In-Memory Store:

using BackWave.Storage.InMemory;
 
builder.Services.AddBackWave(backwave =>
{
    backwave.UseStore(_ => new InMemoryJobStore());
    // ... UseJobs + AddWorkerGroup
});

Wiring a Networked Adapter (Postgres):

using BackWave;
using BackWave.Postgres;
 
builder.Services.AddBackWave(backwave =>
{
    backwave.UseStore(_ => new PostgresJobStore(new PostgresStoreOptions
    {
        ConnectionString = connectionString,
        AutoMigrate = true, // embedded schema self-applies on startup
    }));
    // ... UseJobs + AddWorkerGroup
});

With AutoMigrate = true the adapter's embedded schema self-applies on startup, so there is no manual migration step. Switching to SQL Server is the same shape with SqlServerJobStore and SqlServerStoreOptions.

Verify the install#

The fastest sanity check is to wire the In-Memory Store, declare a single [Job], enqueue it, and confirm the handler runs. That's exactly the Quickstart flow. From there, see Configuration to tune Worker Groups, retries, leases, and Concurrency Limits.