SQL Compatibility Roadmap

The staged engineering plan for making the CSharpDB SQL dialect broader, safer, measurable, and predictable across direct, remote, ADO.NET, and EF Core surfaces.

Roadmap is not availability. This page describes sequencing and current development progress. Use the SQL Compatibility Matrix for the tested status, limitations, applicable surfaces, and proof IDs of a specific feature.

Development snapshot: July 17, 2026. A milestone is complete only when its required behavior, persistence, metadata, negative cases, and applicable surface tests pass. A partial milestone can contain useful supported rows while adjacent rows remain unsupported.

Milestone Status

#MilestoneStatusCurrent boundary
1 Dialect contract and public compatibility matrix Implemented Machine-readable manifest, generated page, schema/proof validation, documentation checks, navigation, and CI/Pages gates are present as a development preview. Snapshot creation and tagged-release validation tooling is now present, but no immutable release snapshot has been published yet and the public page does not yet default to a latest-release snapshot.
2 Persistent constraints, DEFAULT, and CHECK Partial Literal/NULL defaults, DEFAULT markers, DEFAULT VALUES, named/unnamed row-local checks, NOT NULL enforcement, SQL three-valued logic, serializer/reopen coverage, rename preservation, and core catalogs are implemented. Additive metadata now round-trips through direct, HTTP, gRPC, DevOps scripting, and table archives. Stable ids, statement-time defaults, and every mutation/import path remain.
3 Generalized keys and foreign keys Core constraints implemented Persisted named/unnamed logical primary and unique keys, including composite tuples, preserve legacy single INTEGER identity behavior. Column/table scalar and composite foreign keys now provide ordered candidate-key/type/collation validation, MATCH SIMPLE, immediate RESTRICT/CASCADE, reopen, dependency repair, ordered catalogs, ADO.NET, direct/REST/gRPC, archives, and schema tooling. Additional actions, deferrability, stable ids, concurrency/cycle qualification, and EF composite-FK generation remain.
4 Practical ALTER TABLE Core rewrite implemented Direct metadata operations cover SET/DROP DEFAULT, validated SET/DROP NOT NULL, and validated ADD/DROP named CHECK. Unconstrained DROP COLUMN now streams rows into a shadow B+tree and swaps the catalog root transactionally. Populated ADD COLUMN with a typed literal default uses the same path and preserves row ids and indexes. Structural changes reject direct/transitive stored-view, cross-trigger-body, and applicable validation-rule expression dependencies before mutation. Failed writes make both explicit transaction APIs rollback-only. Type/collation/key-shape changes, dependency rewriting, deterministic fault injection, and crash-recovery qualification remain.
5 UNION ALL and compound-query semantics Core implemented Duplicate/NULL preservation, branch naming and type checks, nested operands, view serialization, global ordering/pagination, lazy right-branch execution, cancellation, and collation-aware distinct behavior have focused core coverage. Dedicated transport and EF corpus rows remain partial.
6 Window functions in functional tiers Experimental core implemented A bounded in-memory Tier-1 slice implements ranking and aggregate windows with partitioning, ordering, peer-aware default frames, prepared execution, cancellation, and explicit rejection tests. Star and mixed-expression projections preserve SELECT-list order without exposing hidden window slots, and long evaluation/sort loops poll cancellation. Explicit frames, advanced functions, incompatible stages, an external-sort spill substrate, and large-partition production claims are not yet available.
7 Function catalog and coverage Core metadata implemented A central built-in registry now records canonical names, aliases, kind, arity, accepted/return types, null behavior, volatility, default/check eligibility, collation behavior, and semantics. sys.functions exposes built-ins, aliases, and registered callbacks. Binder diagnostics, scalar/batch/folded parity, generated reference tables, and broader workload qualification remain.
8 Generated SQL and ORM compatibility In progress Identifier quoting is centralized. The EF provider emits and executes DEFAULT VALUES, typed literal defaults, create-table checks, composite primary keys, and composite unique/non-unique indexes; composite-key CRUD and duplicate enforcement are covered, and write failures use the expected EF update exception. Composite foreign keys, standalone key changes, a broader executable EF/ADO corpus, structured generated values, migration rewrites, and remote replay remain.
9 Metadata catalogs and introspection Partial sys.columns.column_default, sys.check_constraints, sys.key_constraints, sys.functions, and ordered scalar/composite pairs in sys.foreign_keys are present. ADO.NET exposes restrictions, defaults, checks, ordered logical keys/key columns, ordered foreign-key pairs, and richer accurate reader metadata; constraint metadata also round-trips through schema scripting and direct/HTTP/gRPC/archive models. Binder-produced result lineage, stable schema ids, and fully normalized constraint/FK catalogs remain.
10 Physical EXPLAIN and EXPLAIN ANALYZE Prerequisites in progress The existing EXPLAIN ESTIMATE FOR rowset contract remains unchanged, now follows centralized read-only transaction routing, and discovers/rebinds prepared target parameters. The plan-only/runtime split, immutable shared physical-plan descriptor, per-node counters, redaction, read-only profiling, and transport/Admin presentation remain.
11 Compatibility release qualification In progress Snapshot tooling and a tagged-release gate now require a clean version-aligned tag, strict SemVer progression, and a schema-valid, newly tracked immutable manifest snapshot; the gate also checks canonical proof/feature parity, verified-commit ancestry, and protects prior release snapshots from modification. Full legacy-fixture, transport/provider replay, performance-budget, rollback/upgrade, and crash-recovery qualification remain.

Current Development Slice

  • A frozen 128-character identifier contract with double-quoted identifiers and doubled-quote escaping.
  • SQL comparison and Boolean three-valued logic, including CHECK semantics where only false rejects.
  • Persisted typed-literal/NULL defaults and explicit omission versus NULL versus DEFAULT behavior.
  • Named/unnamed column/table checks, update prevalidation, reopen persistence, dependency-aware rename/drop behavior, and core catalogs.
  • Logical composite primary/unique keys plus scalar/composite foreign keys with MATCH SIMPLE, immediate RESTRICT/CASCADE, persistence, ordered metadata, and transport/archive/tooling preservation.
  • UNION ALL bag semantics with lazy branch concatenation, type checks, collations, outer pagination, and cancellation cleanup.
  • ALTER dependency preflight for stored views, triggers, and validation rules, plus rollback-only parity for both explicit transaction APIs.
  • Window star/mixed projections that preserve public column shape, and read-only/prepared-parameter prerequisites for future physical EXPLAIN work.
  • Immutable compatibility snapshot creation and tagged-release validation scripts wired into the release workflow.
  • EF Core identifier quoting plus literal-default, create-table CHECK, zero-writable-column DEFAULT VALUES, and composite-key/index support.
Qualification boundary. Literal defaults do not include CURRENT_TIMESTAMP or arbitrary expressions. CHECK expressions reject parameters, functions, subqueries, and qualified references. Window execution is not production-qualified for large partitions until bounded memory and spill cleanup exist. Composite foreign keys are implemented for MATCH SIMPLE plus immediate RESTRICT/CASCADE; additional actions, deferrability, deep cascade/cycle qualification, and EF composite-FK generation remain.

Compatibility Rules

  • Every manifest row describes one narrow behavior and separates availability from roadmap state.
  • Supported rows need positive execution evidence. Partial rows also need an explicit limitation or rejection proof.
  • Persistent DDL needs parser, execution, reopen, and catalog evidence.
  • Direct, ADO.NET, REST, gRPC, EF query, and EF migration facets are qualified independently.
  • Unsupported syntax must fail clearly; the engine and provider must not silently omit schema semantics.
  • No aggregate compatibility percentage is published because it would conceal feature and surface weighting.

Verification Gates

dotnet build CSharpDB.slnx -c Release
dotnet test tests\CSharpDB.Tests\CSharpDB.Tests.csproj -c Release
dotnet test tests\CSharpDB.Data.Tests\CSharpDB.Data.Tests.csproj -c Release
dotnet test tests\CSharpDB.EntityFrameworkCore.Tests\CSharpDB.EntityFrameworkCore.Tests.csproj -c Release
dotnet test tests\CSharpDB.Api.Tests\CSharpDB.Api.Tests.csproj -c Release
dotnet test tests\CSharpDB.Daemon.Tests\CSharpDB.Daemon.Tests.csproj -c Release
pwsh -File scripts\Build-SqlCompatibilityMatrix.ps1 -Check
pwsh -File scripts\Test-Documentation.ps1

# Release preparation and tag gate
pwsh -File scripts\New-SqlCompatibilityReleaseSnapshot.ps1 -Version <version> -VerifiedCommit <sha>
pwsh -File scripts\Test-SqlCompatibilityRelease.ps1 -Version <version> -TagCommit <sha>

Related Documentation

Compatibility Matrix

Feature-level status, facets, limitations, and proof IDs

SQL Source Reference

Current syntax and behavior of the CSharpDB dialect

Product Roadmap

Broader product direction beyond SQL compatibility