By SnowBankSDK
Build correct FoundationDB layers and distributed systems in .NET using SnowBank SDK: key/value encoding, Directory layer, transactions with retry loops, binary Slice handling, and advanced patterns like change feeds, leases, and fencing
Advanced engineering for sophisticated FoundationDB layers with the .NET client (FoundationDB.Client / SnowBank) — the cluster model and transaction lifecycle (proxies, resolvers, tlogs, storage servers, the sequencer/version clock), latency/throughput optimization (batching reads with GetValuesAsync / Task.WhenAll, removing round-trip dependencies, snapshot reads), high-contention avoidance, and distributed patterns (change feeds, version-stamp logs, watch fan-out, version-as-clock leases, retention, fencing/tombstones). Use when building or reviewing a performance-sensitive or distributed layer (a change feed, queue, pub/sub, worker pool, multi-node observable view), tuning transaction latency/throughput, or reasoning about conflicts, the 5-second limit, or cross-node liveness. Builds on the foundationdb-keys-and-layers and foundationdb-transactions skills — read those first.
How to correctly encode keys and values, use subspaces and the Directory layer, and write custom "Layers" with the FoundationDB .NET client (FoundationDB.Client / SnowBank). Use whenever code reads or writes FoundationDB keys, builds tuple keys, uses subspace.Key(...)/FdbValue/TuPack, resolves a subspace/location, or defines a class that stores data in FoundationDB (a "Layer", e.g. a map, index, queue, document collection). Read this BEFORE writing or reviewing any such code.
How to correctly run transactions with the FoundationDB .NET client (FoundationDB.Client / SnowBank) — the ReadAsync/WriteAsync/ReadWriteAsync retry loop, idempotency, the 5-second limit, size limits, atomic mutations, snapshot reads, conflict ranges, and watches. Use whenever code opens a transaction, calls db.ReadAsync/WriteAsync/ReadWriteAsync, handles fdb retry/conflict errors, designs a read-modify-write, or worries about transaction conflicts and consistency. Pairs with the foundationdb-keys-and-layers skill.
How to correctly use the Slice type and its companions (SliceReader, SliceWriter, SliceOwner) for binary data in the FoundationDB .NET client / SnowBank.Core codebase. Slice is a readonly struct (namespace System) — the logical equivalent of ReadOnlyMemory<byte> with many helpers. Use whenever code constructs or reads a Slice, converts between bytes and other types (Slice.FromBytes/FromStringUtf8/FromInt32/FromFixed64/ToInt64/ToStringUtf8/AsSlice/ToArray), builds or parses a binary buffer (SliceWriter/SliceReader), rents pooled buffers (SliceOwner/ArrayPool), or worries about Nil-vs-Empty, endianness, or which integer encoding to use. For the Span<byte>-first equivalents and the low-level buffer/pool machinery, see the bundled reference files.
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
C#/.NET binding for the FoundationDB client library.
To get started, install the FoundationDB.Client package into your application.
dotnet add package FoundationDB.Client
You will also probably require the FoundationDB.Client.Native package that redistributes the native FoundationDB Client libraries for your platform: fdb_c.dll on Windows, libfdb_c.so on Linux, and libfdb_c.dylib on macOS. They are available for x64 and arm64.
dotnet add package FoundationDB.Client.Native
For local development, you can use .NET Aspire to quickly spin up a working environment using a locally hosted Docker container.
Note: Using .NET Aspire for local development requires Docker Desktop on Windows.
While you can use the binding without dependency injection, it is very easy to register the IFdbDatabaseProvider service with the DI container and inject it into any controller, razor page, or other service that needs to query the database.
You can decide to manually configure the database connection, in which case you will need to provide a valid set of settings (API level, root path, ...) as well as copy a valid fdb.cluster file so that the process can connect to an existing FoundationDB cluster.
Alternatively, you can use the .NET Aspire integration to automatically setup a local FoundationDB Docker container, and inject the correct connection string.
In your Program.cs, you should register FoundationDB with the DI container:
using FoundationDB.Client; // this is the main namespace of the library
var builder = WebApplication.CreateBuilder(args);
// ...
// Hook up FoundationDB types and interfaces to the DI container.
// You MUST select the appropriate API version that matches the target cluster.
// For example, '730' requires at least FoundationDB v7.3.x
builder.Services.AddFoundationDb(730, options =>
{
// auto-start the connection to the cluster on the first request
options.AutoStart = true;
// you can configure additional options here, like the path to the .cluster file, default timeouts, ...
});
var app = builder.Build();
// ...
// note: you don't need to configure anything for this step
app.Run();
This will register an instance of the IFdbDatabaseProvider singleton, that you can then inject into other types.
It is possible to add a FoundationDB cluster resource to your Aspire application model, and pass a reference to this cluster to the projects that need it.
For this, you will need to install the following NuGet packages:
In the AppHost project:
dotnet add package FoundationDB.Aspire.Hosting
In each of the projects that need to connect to the FoundationDB cluster:
dotnet add package FoundationDB.Aspire
For local development, a local FoundationDB node will be started using the foundationdb/foundationdb Docker image, and all projects that use the cluster reference will have a temporary Cluster file pointing to the local instance.
Note: You must have Docker installed on your development machine. See the Aspire getting started guide for details.
In the Program.cs of your AppHost project:
private static void Main(string[] args)
{
var builder = DistributedApplication.CreateBuilder(args);
// Define a locally hosted FoundationDB cluster
var fdb = builder
.AddFoundationDb("fdb",
apiVersion: 730,
root: "/Tenant/ACME/MySuperApp/v1",
clusterVersion: "7.4.6",
rollForward: FdbVersionPolicy.Exact
);
// Project that needs a reference to this cluster
var backend = builder
.AddProject<Projects.AwesomeWebApiBackend>("backend")
//...
.WithReference(fdb); // register the fdb cluster connection
npx claudepluginhub snowbanksdk/foundationdb-dotnet-client --plugin foundationdb-dotnet-skillsComprehensive .NET backend development with C#, ASP.NET Core, Entity Framework Core, and Dapper for production-grade applications
Comprehensive .NET development skills and agents for Claude Code - covering C#, F#, Akka.NET, Aspire, testing frameworks, and specialized tools
Expert agent on .NET microservices architecture, containerization, Docker, DDD, CQRS, and cloud-native patterns based on Microsoft's official guide
Official Claude plugin for Azure Cosmos DB (NoSQL). Bundles skills for data modeling, partition key design, query optimization, SDK best practices, indexing, vector search, full-text search, global distribution, security, and more.
Database plugin for nosql-data-modeler
Create, connect, and interact with an AlloyDB for PostgreSQL database and data.