Persistence contracts for modular .NET systems
Model your domain and access patterns in a single manifest. Storage intent, versioned and portable.
manifest.jsonTranslate the same manifest to multiple providers without changing your application code.
Translation layerBuilt for modular .NET systems with clean integration and zero provider lock-in.
.NET 8+Indexes, queries, and concurrency are first-class citizens in the contract. Make performance explicit.
Intent ⟶ NativeVersion manifests, evolve safely, and migrate with confidence across environments.
MigrationsMIT-licensed and community driven. Use it, contribute, and build the persistence layer you trust.
Open source · MITExtensible platforms ship as many independent modules. Each module needs to persist data — but no module should dictate the host's database stack.
Storage intent belongs to the module. Storage technology belongs to the host.
Frameworks such as Elsa, Orchard Core, and ABP all show the same pattern: modules need persistence, while host applications need freedom to choose the database provider. Groundwork gives modules a contract for storage intent that travels across providers — without a hard dependency on EF Core or one engine.
Groundwork draws a clean line between what a module needs to express about its data and what the host application controls about how that data is stored.
The same pattern shows up across workflow engines, CMS platforms, integration catalogs, multi-tenant settings, and runtime-defined business objects.
A workflow, CMS, or application module defines an entity — an approval rule, a content metadata record, an integration catalog item, a tenant setting, or a runtime-defined business object.
It declares queryable fields like status, owner, tenant, key, or category. Groundwork validates the manifest against the configured provider and materializes the right storage shape — relational tables and indexes, or document collections and indexes — without the module knowing which.
public sealed class ApprovalRuleStorage : StorageManifest<ApprovalRule> { public ApprovalRuleStorage() : base("approval_rules") { Serialization.UseJson(); Concurrency.UseOptimistic(r => r.Version); Indexes.On(r => r.TenantId); Indexes.On(r => r.Status); Indexes.On(r => r.OwnerId); } }
A module's storage manifest stays the same. The host picks the provider that fits the deployment — and Groundwork materializes the right physical shape for it.
Local development, samples, integration tests, and small single-node deployments — zero infrastructure.
Enterprise relational workloads with existing tooling, backups, and operational practice.
Modern relational workloads with rich indexing and JSON support — a common default for new systems.
Document-shaped workloads where flexible schemas and per-document indexes are the right fit.
Groundwork is not a replacement for EF Core. It's a smaller persistence contract for the parts of a system where coupling every module to one ORM is the wrong trade-off.
Every transition is explicit: declare, validate, then materialize. Nothing silently changes a database behind your back.
Describe units, indexes, query capabilities, and concurrency through a provider-neutral StorageManifest.
Providers report capabilities. Plans surface gaps and history before anything touches a database.
Application code uses one document-store contract across SQLite, SQL Server, PostgreSQL, and MongoDB.
Everything is declared, inspectable, and provider-aware — without surrendering provider freedom.
Declare units, fields, and contracts once — independent of any database engine.
Query semantics travel with the manifest. Unindexed portable queries fail clearly.
Version tokens are first-class — surfaced consistently across providers.
Each provider reports what it supports. Manifests are checked before execution.
Plans are explicit, inspectable artifacts — never silent runtime side effects.
One contract for document access across relational and document backends.
SQLite, SQL Server, PostgreSQL, and MongoDB ship as discrete provider packages.
Promote hot indexed paths to provider-native shapes, benchmark-gated and explicit.
One declaration; the same indexes, concurrency, and serialization across every supported backend.
// Declare storage intent once — portable across providers. public sealed class SupportTicketStorage : StorageManifest<SupportTicket> { public SupportTicketStorage() : base("support_tickets") { Serialization.UseJson(); Concurrency.UseOptimistic(t => t.Version); // Declared indexes — portable query semantics Indexes.Unique(t => t.TicketNumber); Indexes.On(t => t.CustomerId); Indexes.On(t => t.Status); Indexes.On(t => t.AssigneeId); Indexes.On(t => t.Priority); } }
Each provider package translates manifests into its native shape — and reports honestly about its capabilities.
The same manifest carries from local SQLite through production PostgreSQL or MongoDB — without touching the domain.
var ticket = await store.GetByIndexAsync( t => t.TicketNumber, "TCK-10472" ); ticket.Status = TicketStatus.Resolved; await store.UpdateAsync(ticket); // optimistic
Runs unchanged on: SQLite / PostgreSQL / MongoDB
Groundwork's value comes from what it refuses to do as much as what it offers.
Groundwork is open source and MIT licensed, so teams can inspect the implementation, extend providers, fork when needed, and embed it in their own .NET systems without vendor lock-in.
Inspect the implementation, extend providers, fork when needed, and build on Groundwork without a proprietary runtime boundary.
Read the implementation. No hidden runtime.
Adapt or extend providers when your stack needs it.
Embed it in commercial systems without lock-in.
Use Groundwork as an MIT-licensed foundation for provider-neutral persistence in .NET applications.