NGB Platform v3.0.0 is out.
This release is different from the previous major NGB releases.
There is no single new feature at the center of it.
Instead, v3.0.0 focuses on the platform itself: architecture boundaries, data-access performance, reporting, reliability, testing, and deployment contracts.
It is also a breaking release.
Clearer architecture boundaries
One of the biggest changes in 3.0 is making infrastructure ownership explicit.
Several responsibilities that previously leaked across packages now have dedicated boundaries:
-
NGB.Platform.Hosting.AspNetCore— shared authentication, branding, CORS, health responses, and HTTP error handling -
NGB.Platform.Runtime.Hosting— runtime startup validation -
NGB.Platform.PostgreSql.AspNetCore— PostgreSQL-specific HTTP error mapping and health checks -
NGB.Platform.BackgroundJobs.PostgreSql— PostgreSQL-backed Hangfire storage and inspection
The goal is simple: provider-neutral platform code should not depend on PostgreSQL or hosting implementation details just because an application happens to use them.
Architecture tests now enforce these dependency directions.
For custom NGB hosts, this means package references, namespaces, and composition roots need to be updated when moving from 2.x to 3.0.
Reducing N+1 database work
A large part of this release was spent going through data-access paths across:
- catalogs
- documents
- operational registers
- reference registers
- reporting
- vertical-specific workflows
Several operations that previously required repeated individual reads now use batched access.
This reduces database round trips and unnecessary allocations, especially when resolving related entities or processing larger result sets.
I intentionally do not attach a universal percentage speedup to this release. Performance depends heavily on the workload, dataset, hardware, and configuration.
The performance test framework now includes reproducible run manifests and tooling for controlled before/after comparisons instead.
Reporting changed significantly
Reporting received some of the largest contract changes in 3.0.
Reports now support cursor-based continuation instead of relying on increasingly large offsets.
Execution responses can return:
hasMorenextCursor- nullable totals
Composable reports can also load nested groups incrementally using their group paths.
For large exports, complete XLSX downloads now use a streaming path rather than building the whole export as one bounded in-memory report result.
There are also per-instance admission limits for report execution. Clients need to handle HTTP 429 and Retry-After when the configured reporting budget is exhausted.
These changes make report execution more predictable as datasets grow.
Bounded requests
3.0 also makes several limits explicit.
Catalog and document paging is bounded, and large clients should follow continuation cursors instead of increasing offsets indefinitely.
Document payloads also have limits for tabular parts, rows, and cells.
I prefer explicit limits over allowing a single request to consume arbitrary resources and hoping it remains manageable in production.
100% coverage gates
One of the biggest changes to the release process is testing.
The NGB 3.0 quality gates require:
- 100% backend line coverage
- 100% backend branch coverage
- 100% backend method coverage
- 100% frontend line coverage
- 100% frontend branch coverage
- 100% frontend function coverage
- 100% frontend statement coverage
These requirements apply to eligible production source.
The validation also checks coverage per file and source-file completeness, so a high aggregate number cannot hide an untested production file.
The backend gate includes integration and volume tests using isolated PostgreSQL fixtures.
The frontend gate includes:
- type checking
- public-export validation
- unit tests
- browser tests
- Playwright E2E tests
A release requires both complete runners to pass.
Coverage itself is not treated as proof that the software is correct, but it is now one of the release gates rather than an informational metric.
Integration test isolation
The integration-test infrastructure was also reworked.
Database-backed test collections now use controlled fixture startup and stronger isolation.
Regression tests cover areas such as:
- deterministic paging
- database migration concurrency
- query counts
- full report exports
- application startup
- vertical workflows
This work exposed several issues that were difficult to see when tests shared too much infrastructure state.
Performance testing
The NGB performance-testing workspace was reorganized as part of this release as well.
The Property Management suite now includes scenarios around:
- reads
- reporting
- document lifecycle operations
- posting
- capacity
- contention
- write-heavy workloads
- breakpoint testing
- focused diagnostic probes
The framework records workload configuration and revision identity so results can be compared offline without losing the context in which a run was executed.
Trade and Agency Billing currently have lighter smoke scaffolds, while CRM does not yet have a dedicated k6 suite.
I think it is important to state that explicitly instead of implying that all four verticals currently have identical performance-test depth.
Four verticals move together
NGB currently includes four vertical applications:
- Property Management
- Trade
- Agency Billing
- CRM
All of them move to 3.0.0 together.
The release also includes:
- 20
NGB.Platform.*NuGet packages @ngbplatform/ui@3.0.0- APIs
- migrators
- background-job hosts
- watchdogs
- web applications
Backend components target .NET 10.
Breaking changes
This is a coordinated breaking release.
Mixing NGB 2.x and 3.x packages or web applications is not supported.
Public service and repository interfaces changed, several DTOs changed, reporting contracts changed, and hosting responsibilities moved between packages.
Applications consuming NGB packages should be recompiled against 3.0 instead of swapping individual assemblies into an existing 2.x deployment.
The migration guide covers the complete upgrade sequence:
https://docs.ngbplatform.com/guides/migrating-to-3.0.html
What v3.0 means for NGB
Previous NGB releases added major platform capabilities such as reusable packages, CRM, Document Actions, and Work Center.
v3.0 is more about strengthening the foundation underneath them.
The platform now has clearer architecture boundaries, more bounded execution paths, better behavior for large report workloads, fewer repeated database reads, and much stricter release validation.
There is still a lot to build.
But before adding more layers to the platform, I wanted the existing ones to have stronger boundaries and better operational characteristics.
NGB is open source and built with .NET 10 and PostgreSQL.
GitHub:
https://github.com/ngbplatform/NGB
NGB Platform v3.0.0 release:
https://github.com/ngbplatform/NGB/releases/tag/v3.0.0
Documentation:
Tags: dotnet, opensource, architecture, postgresql
Top comments (0)