BLite v4.0.2 released — Async-Only API, Server Mode, OLAP boost & storage overhaul

[mrdevrobot]

Hey everyone! 👋

We're excited to announce the release of BLite v4.0.2 — a major update that reflects nearly three weeks of intensive work, from analytical query optimizations to a deep storage layer rewrite, a new server mode, and a fully async CRUD API.

If you've been on any 3.6.x release, here's everything you missed. ☕

---

🚀 Biggest Change: Async-Only CRUD API (v4.0.0)

The most significant breaking change in this cycle: all CRUD methods are now exclusively async. Synchronous overloads have been removed. If you're upgrading, add await to your calls:

// Before (no longer supported)
collection.Insert(entity);

// Now
await collection.InsertAsync(entity);

This allowed us to massively simplify the internal engine, eliminate potential deadlocks, and pave the way for more advanced concurrency features going forward.

---

🏗️ Server Mode & Session API (v3.8.0)

One of the most requested features: BLite now has a server mode with per-connection isolated transaction contexts.

• BLiteSession — each connection gets its own independent transactional context, ideal for multi-user and networked scenarios
• Server() config — new fluent entry point for configuring BLite in server mode
• BLiteMigration — built-in utility to migrate databases between single-file and multi-file formats
• KvGetWithExpiry — key-value retrieval with native TTL support
• ImportDictionary — bulk import from IDictionary sources
• Improved concurrency in multi-session environments via a dedicated metadata lock

---

⚡ Much Faster OLAP Queries (v3.7.0)

Analytical queries — aggregations, GroupBy, full collection scans — have been significantly optimized. If you use BLite for reporting or OLAP workloads, you should see a noticeable performance jump with zero code changes on your end.

---

🔧 Storage Layer Overhaul (v3.8.0)

The storage engine received a series of critical fixes and structural improvements:

• Replaced SemaphoreSlim with ReaderWriterLockSlim in PageFile — eliminates concurrent read/write race conditions
• Bit-tagged page IDs — page IDs now encode their owning file directly in the tag, eliminating routing collisions in multi-file databases, WAL recovery, and index scans
• Non-blocking checkpoints with deferred metadata writes — reduces write stalls during heavy workloads
• Lazy<PageFile> for collection files — avoids unnecessary file handle allocations at startup
• Post-dispose safety hardening in PageFile: volatile _disposed, ThrowIfDisposed, field nulling on close
• Read lock applied to netstandard2.1's ReadPageAsync to prevent races with EnsureCapacityCore

---

🛡️ Source Generator Hardening (v3.6.6–3.6.9)

The source generator — responsible for auto-generating entity mappers — received several important fixes:

• BLITE001: compile-time error when a type is skipped due to exceeding nesting depth (max raised to 20 levels) — no more silent skips
• BLITE003: compile-time error when two entity types in the same DocumentDbContext resolve to the same collection name — prevents silent data corruption at runtime
• Fixed mapper name collisions when entity types share a simple class name across different namespaces
• Fixed .ToCollection(name) parsing in OnModelCreating fluent chains, including const string references

---

🐛 Other Notable Fixes

• ObjectId ordering (v4.0.1) — comparison and sort on ObjectId fields now works correctly
• Execute deadlock (v4.0.1) — resolved a deadlock that could occur under concurrent Execute calls
• AddString UTF-8 (v3.6.6) — EnsureCapacity now uses the actual UTF-8 byte count instead of character count — critical fix for strings containing multi-byte characters

---

📦 NuGet Packages

All packages are available on NuGet at version 4.0.2:

• BLite
• BLite.Bson
• BLite.Caching
• BLite.Core
• BLite.SourceGenerators

---

As always, the full CHANGELOG has every detail. Questions, feedback, or issues? Open a thread here or file an issue — we're happy to help. 🙌

[AFunDog]

Hi, first of all, great work on BLite — the design (especially zero-allocation and source generators) looks very promising.

I have a question regarding runtime usage:

Is there currently any support (or planned support) for an in-memory database mode?

For example, something similar to:

• SQLite :memory:
• or a mode where the database operates entirely in RAM without persisting to disk

My use case is:

• high-performance in-memory data handling
• optional/manual persistence (rather than always file-based)

From the documentation and examples (e.g. new DocumentDb("mydb.blite")), it seems BLite is currently file-based by design.

So I’m wondering:

• Is an in-memory mode possible with the current architecture?
• Or would this go against BLite’s design goals (e.g. WAL, ACID, storage engine)?

Thanks in advance!