Testing NGB Platform Beyond a Small Demo Dataset with k6 and TypeScript

I recently released NGB Platform v1.1.1.

The main addition is the first NGB Performance Tests Framework.

This is not just a set of endpoint benchmarks.

NGB Platform is an open-source, metadata-driven business platform for building accounting-first industry solutions. The goal is not to build isolated CRUD applications, but complete business applications where documents, catalogs, accounting, audit history, workflows, reports, and background processes are part of the same architecture.

So performance testing has to follow the same idea.

It needs to test real platform behavior, not only isolated HTTP latency.

Why performance testing matters for NGB

In many applications, performance testing starts with a few simple endpoint checks.

That can be useful.

But it does not answer the most important questions for a business platform.

For NGB, the important questions are different:

• Can users browse documents while other users are posting documents?
• Can reports stay usable as data volume grows?
• Can audit history remain readable under pressure?
• Can accounting effects be opened quickly after posting?
• Can document flow stay responsive?
• Can the platform preserve business correctness while handling mixed read/write workloads?

NGB is accounting-first.

That means a posted document is not just a saved record.

It can produce:

• Accounting entries
• Audit records
• Document relationships
• Reportable business effects
• Operational state changes

So performance testing has to cover business workflows.

Not just endpoints.

What was added in v1.1.1

NGB v1.1.1 adds a dedicated performance testing workspace based on:

• Grafana k6
• TypeScript
• Reusable scenario profiles
• Keycloak tester authentication
• Custom metrics
• Thresholds
• Vertical-specific workload packages

The repository now includes:

performance-tests/
  ngb-performance-tests-framework/
  ngb-property-management-perf/
  ngb-trade-perf/
  ngb-agency-billing-perf/
  scripts/

The most important part is the boundary.

The shared framework is vertical-neutral.

It knows platform concepts:

• Auth
• Health
• Metadata
• Catalogs
• Documents
• Reports
• Accounting effects
• Document flow
• Audit
• Scenarios
• Metrics
• Thresholds

It does not know Property Management, Trade, or Agency Billing.

Vertical packages define their own document types, catalog types, report IDs, fixtures, and workload mixes.

That separation matters.

I do not want performance testing to become another place where platform and vertical layers start leaking into each other.

The first serious validation run

For the first serious validation run, I used the NGB Property Management vertical.

The environment was intentionally local:

• Local Docker deployment
• PostgreSQL database around 19GB
• Around 1.7M business documents
• Around 27M audit log records

This is not a third-party audited benchmark.

It is not a claim of unlimited scale.

But it is an important production-readiness signal.

NGB is no longer tested only as a small demo dataset.

It now has repeatable performance workloads running against real platform behavior and non-trivial data volume.

What was tested

The performance framework includes multiple workload profiles.

Some of the important ones are:

• Smoke
• Baseline
• Platform read
• Platform reporting
• Platform read capacity
• Platform mixed capacity
• Platform breakpoint
• Document lifecycle
• Audit
• Maintenance
• Concurrency
• Business day
• Write-heavy

The goal is not to run all of them every time.

Different profiles answer different questions.

Platform read capacity

This profile focuses on read-heavy platform behavior.

It helps validate whether common read paths stay stable under high concurrency.

Platform mixed capacity

This is one of the most important profiles.

It combines different types of platform activity instead of testing only one endpoint.

The workload includes document reads, platform reads, reporting, audit-related operations, accounting effects, document flow, and other common application behavior.

Write-heavy

This profile is more aggressive.

It exercises document create/update/post operations while the system is also reading accounting effects, audit history, document flow, and reports.

For an accounting-first platform, this is one of the most important scenarios.

Writes are not just writes.

They create durable business consequences.

Selected results

Here are selected results from the run set.

Mixed capacity

The mixed-capacity profile ran for around 80 minutes.

Results:

• 9.5M+ requests
• 1,000 peak virtual users
• 0 dropped iterations
• 0 business failures

This matters because the workload was not a single endpoint benchmark.

It exercised mixed platform behavior under sustained load.

Read capacity

The read-capacity profile pushed read pressure higher.

Results:

• 10.8M+ requests
• 1,400 peak virtual users
• 0 dropped iterations
• 0 business failures

The important signal here is the combination of request volume, concurrency, and correctness.

Not just one latency number.

Write-heavy workload

The write-heavy profile ran document lifecycle operations under pressure.

Results:

• 1.75M+ requests
• Document create/update/post activity
• Accounting effects reads
• Audit reads
• Document flow reads
• Report execution under write pressure
• 0 dropped iterations
• 0 business failures

This is the kind of workload that matters for NGB.

The platform needs to stay usable while documents are being created, posted, audited, explained, and reported on.

What I look at

For this framework, one metric is not enough.

I care about several signals together:

• HTTP failure rate
• Business operation failure rate
• Dropped iterations
• p95 latency
• p99 latency
• Checks
• Thresholds
• Report execution behavior
• Operation-level breakdowns
• Document post latency
• Accounting effects latency
• Audit latency
• Document flow latency

A good result is not just:

The test finished.

A good result means:

• No silent business failures
• No dropped iterations for the target profile
• No broken checks
• No hidden vertical coupling in the shared framework
• No report path that only works on a tiny dataset

For business software, performance is not only speed.

It is also correctness under pressure.

Why this matters for architecture

NGB is built around several platform-level ideas:

1. Documents represent business intent
   
   Business operations are modeled as documents, not random database updates.

2. Posting creates durable effects
   
   Posted documents can create accounting entries, audit records, operational state, and reportable business consequences.

3. Auditability is part of the platform
   
   The system should explain what happened and why.

4. Reports are connected to business truth
   
   Reporting is not just a separate dashboard layer.

5. Verticals extend the platform
   
   Property Management, Trade, and Agency Billing should reuse the same platform capabilities without duplicating the core engine.

The performance framework follows the same architecture.

The shared framework tests platform concepts.

Vertical packages provide vertical-specific workloads.

That is the same boundary the runtime architecture is supposed to preserve.

What this does not claim

I want to be precise about the result.

This does not mean:

• NGB has been certified by an external benchmark
• NGB has unlimited scale
• A local Docker run is the same as a production Kubernetes deployment
• Every possible workload has been tested

That would be an overclaim.

What it does mean is more practical:

NGB is now tested beyond a toy demo dataset.

It has repeatable performance workloads for real platform behavior.

It can validate documents, posting, audit, accounting effects, document flow, reports, and mixed read/write scenarios against meaningful data volume.

That is a much stronger foundation than only saying:

It works on my machine.

Links

GitHub:

https://github.com/ngbplatform/NGB

Release:

https://github.com/ngbplatform/NGB/releases/tag/v1.1.1

Performance tests workspace:

https://github.com/ngbplatform/NGB/tree/main/performance-tests

Documentation:

https://docs.ngbplatform.com

Website:

https://ngbplatform.com

Final thought

Performance testing business software is not only about latency.

It is about confidence.

Confidence that the platform can preserve correctness under pressure.

Confidence that reports still work when data grows.

Confidence that audit history and document flow remain usable.

Confidence that posting does not become a black box.

NGB v1.1.1 is an important step in that direction.

The platform is no longer validated only by functional demos.

It now has a reusable performance testing framework for real business workloads.

That is the kind of foundation I want for building serious accounting-first business applications.