Node.js 24 and Fastify v6 — Why We Said Goodbye to fast-json-stringify

Fastify v6 has decisively removed fast-json-stringify, its own serialization engine that was a long-standing core identity. This is because the native JSON.stringify in the V8 engine included in Node.js 25 has seen dramatic performance improvements, allowing for blazing-fast speeds without the need for complex schema compilation. As a result, Fastify has shed over 3,000 lines of code, achieving a more lightweight framework while fully leveraging the optimization benefits of the latest runtime.

V8 JSON.stringify Optimizations in Node.js 24 and 25

When building web or API servers, JSON serialization is almost always the primary culprit consuming CPU cycles. To address this bottleneck, Fastify, which we all love, relied on its own formidable third-party engine called 'fast-json-stringify' to pre-compile developer-defined schemas into string assembly code.

However, with the optimizations in modern runtimes, including the V8 13.8 engine in Node.js 25, this paradigm has been completely disrupted. Now, without resorting to complex compilation libraries, the native JSON.stringify can match or even outperform existing custom engines. This remarkable architectural shift is the result of organically combining several clever optimization mechanisms:

Developers no longer need to waste maintenance resources juggling complex optimization libraries. Simply by upgrading the Node.js version, you can cleanly resolve the backend's most chronic computational load using the runtime's own native engine.

Fastify v6's Bold Decision: Removing 3,000 Lines of Custom Engine

Fastify v6 removed over 3,000 lines of custom serialization code because the practical benefits of maintaining a complex runtime compilation approach in modern Node.js environments have disappeared. Through GitHub pull request 6507, the Fastify team completely removed the dependency on the fast-json-stringify library. This at once solved the compilation overhead during initial application startup—previously accepted for the sake of performance—and eliminated the maintenance burden of a massive custom engine.

The secret to how this structural change ensures high performance beyond mere code cleanup is evident in benchmark results within Node.js 25. Below are the figures comparing native serialization throughput against the former custom compiler.

In actual production API environments, the native API now outperforms the old engine for the most frequently exchanged large arrays and standard object formats. While there are areas where the old engine still has an edge, such as date data or very short string structures thanks to schema pre-formatting, the trade-off in maintenance costs for the framework has become less justifiable. Ultimately, the advancement of the runtime itself has begun to overwhelm the artificial tuning of third-party libraries.

Serialization Separation and Response Schema Validation Patterns with Ajv

In Fastify v6, response schemas no longer play a role in accelerating serialization or filtering output data. Serialization is now handled entirely by the V8 engine's ultra-fast native JSON.stringify, and the response schema declared by the developer functions solely for selective data validation via the Ajv engine. While the architecture has become much clearer with the two roles completely separated, there is a crucial point to be aware of when changing your existing usage patterns.

In older versions, properties not defined in the response schema were automatically excluded during serialization. However, because v6 uses native serialization, even fields not in the schema will be exposed to the client without filtering. To prevent the leakage of sensitive data, you must either sanitize response objects directly at the business logic layer or explicitly enable the response validation step.

Below is a simple example of using response schemas in Fastify v6.

fastify.get('/user', {
  schema: {
    response: {
      200: {
        type: 'object',
        required: ['id', 'name'],
        properties: {
          id: { type: 'integer' },
          name: { type: 'string' }
        }
      }
    }
  }
}, async (request, reply) => {
  // v6 주의: 스키마에 없는 'role' 필드가 필터링되지 않고 그대로 출력됩니다.
  return { id: 1, name: '마루', role: 'admin' };
});

By decoupling response validation from serialization, developers can now selectively pay the cost of validation only where needed. For internal APIs where performance optimization isn't critical, you can even skip validation entirely to maximize response speed.

Migration Strategy: What to Prepare Now

Simply upgrading to the latest LTS version of Node.js can significantly reduce CPU resources for serialization without requiring complex architectural changes. Now is the time to actively leverage engine-level optimizations from the runtime's standard spec rather than relying on custom optimization libraries. If you are planning to adopt Fastify v6, we recommend proactive refactoring to identify code that relied on previous schema-filtering behavior and to clearly structure objects in alignment with native serialization specs.

Reference Links