TypeDB C# driver: bringing .NET to TypeDB 3

TypeDB has offered drivers for Rust, Python, Java, and TypeScript since the 3.0 release. The C# driver brings TypeDB to the .NET ecosystem.

The C# driver is a rebuild on the same architectural foundation shared by the Python and Java drivers: a thin language layer over the native Rust core, connected via SWIG-generated P/Invoke bindings. The API has been redesigned to match TypeDB 3.x and to take advantage of modern C# features like nullable reference types and default interface methods.

Architecture

All of TypeDB’s FFI-based drivers follow the same layered model:

C# application → TypeDB.Driver (C# API) → SWIG P/Invoke → 
C FFI → Rust core → gRPC

The Rust core handles connection management, query execution, and the gRPC protocol. SWIG generates C# P/Invoke wrappers from the C FFI layer, and the C# API wraps those in idiomatic interfaces. The C# driver inherits the Rust core’s performance and correctness without reimplementing protocol logic — at the cost of depending on platform-specific native libraries.

The driver is distributed as NuGet packages: one main package plus a platform-specific runtime per target (macOS x64/arm64, Linux x64/arm64, Windows x64). It targets .NET 6.0.

The API

The entry point is TypeDB.Driver(). For example, running it against a local TypeDB CE instance:

using var driver = TypeDB.Driver(
    "localhost:1729",
    new Credentials("admin", "password"),
    new DriverOptions(tlsEnabled: false, tlsRootCA: null)
);
driver.Databases.Create("my-database");

TypeDB 3 distinguishes three transaction types — Read, Write, and Schema — and queries return a Promise<IQueryAnswer> that is resolved explicitly:

using (var tx = driver.Transaction("my-database", TransactionType.Schema))
{
    tx.Query(@"define
        entity person, owns name, owns age;
        attribute name, value string;
        attribute age, value integer;
    ").Resolve();
    tx.Commit();
}

Promise, a term borrowed from Java and Python’s implementation, is not a Task — the network request fires immediately, but the response is only retrieved on .Resolve(). This mirrors the Java driver’s pattern and keeps the API consistent across languages, though C# developers accustomed to async/await might find this old fashioned, but it stems from limitations in the Rust/C# interopability layer.

Responses: concept rows and documents

Query results come in two forms main: concept rows and concept documents (JSON from fetch). A returned IConceptRowIterator implements IEnumerable<IConceptRow>

var answer = tx.Query("match $p isa person, has name $n;").Resolve();
// Standard iteration
foreach (var row in answer.AsConceptRows())
{
    var person = row.Get("p");
    if (person != null && person.IsEntity())
        Console.WriteLine($"IID: {person.AsEntity().IID}");
}
// LINQ
var names = answer.AsConceptRows()
    .Select(row => row.Get("n"))
    .Where(c => c != null && c.IsAttribute())
    .Select(c => c!.TryGetString())
    .ToList();

Trade-offs

Implementing a driver using a shared-core design language has some interesting considerations for both maintainers and users:

1. Platform-specific packages. Separate NuGet runtimes per OS/architecture add setup friction compared to the pure-TypeScript HTTP driver, but enable full gRPC streaming support with significantly better maintainability. As a user, this means you will need to include all the platform-native libraries if you want to move your application across architectures as a binary.
2. No native async/await. The Promise<T> pattern doesn’t integrate with Task-based async pipelines. This is a conscious trade-off since interoperating with a Rust async/await core doesn’t work through SWIG generated wrappers.

In practice, these aren’t seriously limiting factors, just points to keep in mind!

Next steps

The driver is open source under Apache 2.0 in the TypeDB Driver repository. Visit the install page on our docs, or head to the API reference.

And as always, feel free to come and chat with our community on Discord.