Grayworth now brings production server applications onto Gray through a hands-on commercial migration program.
Grayworth has opened commercial access to Gray through a hands-on preview for production server applications. Customers bring an existing API, worker, gateway or data service; Grayworth moves that workload into Gray and supports the deployment through cutover.
The engagement is designed around working software rather than a language demonstration. Grayworth establishes the current service contract, recreates it in Gray, validates response and failure behavior, and runs the new service under production-shaped pressure before traffic moves.
Gray is developed and commercially published by Grayworth. The same team owns the language, virtual machine, native backend, networking stack, database path, developer tools and release process.
Gray combines Live, Adaptive and Static execution with HTTP/1.1, HTTP/2, WebSocket, TLS, structured tasks, readiness-driven PostgreSQL, JSON, classes, packages, a formatter and a language server. Eligible typed code can lower through Gray’s versioned native runtime ABI while unsupported code retains VM fallback.
That vertical design lets Grayworth tune the application language and the pressure-critical runtime together. A database wait, connection deadline, worker replacement or native transition is part of one product contract rather than an integration assembled separately for every service.
Adaptive mode provides the production replacement path. Gray compiles a candidate, waits until the new worker is ready, publishes it, and drains the previous worker while preserving in-flight work.
The first step is a workload review: application boundaries, traffic shape, dependencies, data contracts, deployment topology and the result the customer needs. Grayworth then defines the migration plan and the production acceptance criteria.
During implementation, the original service remains available. Grayworth builds the Gray version, exercises correctness and failure cases, records corrected latency and resources, and prepares a side-by-side cutover with a rollback path.
The finished engagement includes the Gray application, deployment guidance, a reproducible operating record and direct runtime support. The product roadmap is tied to the workload the customer is actually shipping.
Grayworth is accepting server applications where integrated HTTP, TLS, JSON and PostgreSQL can replace meaningful runtime assembly or pressure cost. Production APIs, internal services, gateways and workers are the strongest starting points.
Teams can begin through the commercial preview page with the current stack, service shape and performance or deployment goal. Grayworth scopes and prices the engagement directly.
", "image": "https://grayworth.com/news/media/gray-commercial-preview-16x9.png", "banner_image": "https://grayworth.com/og-news-gray-commercial-preview.png", "date_published": "2026-07-26T09:00:00Z", "date_modified": "2026-07-26T13:00:00Z", "authors": [ { "name": "Grayworth Engineering", "url": "https://grayworth.com/company" } ], "tags": [ "Company", "Gray", "Grayworth", "commercial preview", "server runtime", "application migration" ], "language": "en-US", "_grayworth": { "markdown_url": "https://grayworth.com/news/gray-commercial-preview.md", "word_count": 378, "reading_time_minutes": 2 } }, { "id": "https://grayworth.com/news/gray-formal-http-qualification", "url": "https://grayworth.com/news/gray-formal-http-qualification", "title": "Gray completes three-hour HTTP qualification", "summary": "Gray completed one-hour plaintext, JSON and PostgreSQL route gates with exact delivery checks and zero measured steady-state RSS or descriptor growth.", "content_text": "Three sequential one-hour gates delivered 49,997.81 plaintext requests/s, 39,993.57 JSON requests/s and 3,999.85 PostgreSQL requests/s.\n\nGray’s Static-mode route matrix completed three sequential one-hour qualifications: plaintext HTTP, native JSON and a parameterized PostgreSQL query. The complete run lasted 10,858 seconds, including warmup, settling and transition work between routes.\n\nThe runner performed an exact-response preflight before each load phase. During the hour it preserved wrk2’s corrected-latency output, sampled the Gray process after connection ramp, and failed the route if delivery, response status, process health, memory growth or file-descriptor growth violated policy.\n\nPlaintext achieved 49,997.81 requests/s against 50,000 requested. Corrected p50 was 1.34 ms, p99 was 7.00 ms and p99.9 was 23.87 ms.\n\nThe JSON route encoded a new response for every request through Gray’s native JSON path. It achieved 39,993.57 requests/s against 40,000 requested, or 99.984% delivery.\n\nCorrected p50 was 1.31 ms, p99 was 4.09 ms and p99.9 was 17.30 ms. The Gray process remained at 10,316 KiB RSS across all 358 steady-state samples, with 262 open file descriptors and zero measured growth.\n\nThe plaintext process produced the same resource result: 10,284 KiB RSS in every steady-state sample and no descriptor growth.\n\nThe original PostgreSQL route delivered 3,999.85 requests/s against 4,000 requested with flat resources, but corrected p99 reached 802.82 ms and p99.9 reached 1.55 seconds. The route delivered the work; it did not deliver an acceptable tail.\n\nThat result identified a blocking architecture in the first database path. Each synchronous query occupied a reactor worker until libpq returned, allowing requests to queue even while CPU remained available.\n\nGrayworth subsequently replaced that path with readiness-driven libpq and compiler-hidden handler continuations. The later continuation qualification is reported as a separate product milestone rather than being substituted into this original record.\n\nThe report records the Gray binary SHA-256, application and runner hashes, execution mode, duration, requested rates, connection count, CPU topology, database configuration and all route summaries. The publication renderer refuses incomplete or tampered matrices.\n\nThis is a same-host Gray product qualification, not an official TechEmpower result or a universal language ranking. Its purpose is to establish sustained delivery, corrected latency and resource stability for the declared applications and environment.\n\nThe raw comparison data, methodology and route report remain linked so readers can inspect the result behind the headline.", "content_html": "Three sequential one-hour gates delivered 49,997.81 plaintext requests/s, 39,993.57 JSON requests/s and 3,999.85 PostgreSQL requests/s.
Gray’s Static-mode route matrix completed three sequential one-hour qualifications: plaintext HTTP, native JSON and a parameterized PostgreSQL query. The complete run lasted 10,858 seconds, including warmup, settling and transition work between routes.
The runner performed an exact-response preflight before each load phase. During the hour it preserved wrk2’s corrected-latency output, sampled the Gray process after connection ramp, and failed the route if delivery, response status, process health, memory growth or file-descriptor growth violated policy.
Plaintext achieved 49,997.81 requests/s against 50,000 requested. Corrected p50 was 1.34 ms, p99 was 7.00 ms and p99.9 was 23.87 ms.
The JSON route encoded a new response for every request through Gray’s native JSON path. It achieved 39,993.57 requests/s against 40,000 requested, or 99.984% delivery.
Corrected p50 was 1.31 ms, p99 was 4.09 ms and p99.9 was 17.30 ms. The Gray process remained at 10,316 KiB RSS across all 358 steady-state samples, with 262 open file descriptors and zero measured growth.
The plaintext process produced the same resource result: 10,284 KiB RSS in every steady-state sample and no descriptor growth.
The original PostgreSQL route delivered 3,999.85 requests/s against 4,000 requested with flat resources, but corrected p99 reached 802.82 ms and p99.9 reached 1.55 seconds. The route delivered the work; it did not deliver an acceptable tail.
That result identified a blocking architecture in the first database path. Each synchronous query occupied a reactor worker until libpq returned, allowing requests to queue even while CPU remained available.
Grayworth subsequently replaced that path with readiness-driven libpq and compiler-hidden handler continuations. The later continuation qualification is reported as a separate product milestone rather than being substituted into this original record.
The report records the Gray binary SHA-256, application and runner hashes, execution mode, duration, requested rates, connection count, CPU topology, database configuration and all route summaries. The publication renderer refuses incomplete or tampered matrices.
This is a same-host Gray product qualification, not an official TechEmpower result or a universal language ranking. Its purpose is to establish sustained delivery, corrected latency and resource stability for the declared applications and environment.
The raw comparison data, methodology and route report remain linked so readers can inspect the result behind the headline.
", "image": "https://grayworth.com/news/media/gray-formal-http-qualification-16x9.png", "banner_image": "https://grayworth.com/og-news-gray-formal-http-qualification.png", "date_published": "2026-07-26T09:20:00Z", "date_modified": "2026-07-26T13:00:00Z", "authors": [ { "name": "Grayworth Engineering", "url": "https://grayworth.com/company" } ], "tags": [ "Benchmarks", "Gray benchmarks", "HTTP performance", "corrected latency", "wrk2", "PostgreSQL" ], "language": "en-US", "_grayworth": { "markdown_url": "https://grayworth.com/news/gray-formal-http-qualification.md", "word_count": 375, "reading_time_minutes": 2 } }, { "id": "https://grayworth.com/news/gray-postgresql-continuations", "url": "https://grayworth.com/news/gray-postgresql-continuations", "title": "Gray ships compiler-hidden PostgreSQL continuations", "summary": "Gray handlers can now suspend synchronous-looking PostgreSQL calls on socket readiness, preserving direct code without occupying general task workers.", "content_text": "A 30-second database qualification delivered 7,961.48 requests/s with p99 4.60 ms, 164 simultaneous suspended handlers and zero general task workers.\n\nGray HTTP handlers can now call PostgreSQL in direct source order while the compiler and runtime preserve the suspended continuation. The source reads like a synchronous query, but the reactor is released whenever the database socket is not ready.\n\nThe application does not maintain a pending-request map, write a polling loop or assign every database wait to a general worker. Gray captures the handler state, associates it with the nonblocking libpq operation and resumes the exact continuation when the socket advances.\n\nThe result is a server model in which direct code and cooperative I/O are the same product feature rather than competing programming styles.\n\nConnection creation uses PQconnectStart and PQconnectPoll rather than blocking the process. Query execution sends work nonblockingly, consumes input only when the database socket is ready and returns the connection to the pool after the complete result is decoded.\n\nWhen all pool connections are occupied, new work waits in the Gray scheduler instead of failing immediately or consuming task-worker capacity. A cancellation discards the active connection and replaces it safely before another request can inherit uncertain protocol state.\n\nTyped query failures resume through Gray’s normal error path. Live, Static and Adaptive modes preserve the same language behavior.\n\nThe Static fixture used PostgreSQL 16, a pool of 64 connections, four wrk2 threads and 256 persistent HTTP connections. At 8,000 requested requests/s, Gray achieved 7,961.48 requests/s, or 99.519% delivery.\n\nCorrected p50 was 1.43 ms, p99 was 4.60 ms and p99.9 was 8.74 ms. The sampler observed as many as 164 simultaneously suspended handlers and no general task workers.\n\nAfter the run, active tasks and continuations returned to zero. RSS and file-descriptor counts remained within the gate’s declared limits.\n\nThe protocol suite exercises overlapping database handlers in Live and Static modes, typed errors after suspension, independent HTTP/2 multiplexing, automatic 404 and 500 responses, and Adaptive replacement while an old handler remains in flight.\n\nCancellation tests verify that unfinished database work cannot leak a connection back into the pool. Sanitizer builds cover the same ownership path, and the optimized suite proves the result through the actual HTTP reactor.\n\nReal service capacity will still depend on query cost, database placement, schema, pool size and topology. What changed in Gray is the architecture: one waiting query no longer owns the HTTP reactor.", "content_html": "A 30-second database qualification delivered 7,961.48 requests/s with p99 4.60 ms, 164 simultaneous suspended handlers and zero general task workers.
Gray HTTP handlers can now call PostgreSQL in direct source order while the compiler and runtime preserve the suspended continuation. The source reads like a synchronous query, but the reactor is released whenever the database socket is not ready.
The application does not maintain a pending-request map, write a polling loop or assign every database wait to a general worker. Gray captures the handler state, associates it with the nonblocking libpq operation and resumes the exact continuation when the socket advances.
The result is a server model in which direct code and cooperative I/O are the same product feature rather than competing programming styles.
Connection creation uses PQconnectStart and PQconnectPoll rather than blocking the process. Query execution sends work nonblockingly, consumes input only when the database socket is ready and returns the connection to the pool after the complete result is decoded.
When all pool connections are occupied, new work waits in the Gray scheduler instead of failing immediately or consuming task-worker capacity. A cancellation discards the active connection and replaces it safely before another request can inherit uncertain protocol state.
Typed query failures resume through Gray’s normal error path. Live, Static and Adaptive modes preserve the same language behavior.
The Static fixture used PostgreSQL 16, a pool of 64 connections, four wrk2 threads and 256 persistent HTTP connections. At 8,000 requested requests/s, Gray achieved 7,961.48 requests/s, or 99.519% delivery.
Corrected p50 was 1.43 ms, p99 was 4.60 ms and p99.9 was 8.74 ms. The sampler observed as many as 164 simultaneously suspended handlers and no general task workers.
After the run, active tasks and continuations returned to zero. RSS and file-descriptor counts remained within the gate’s declared limits.
The protocol suite exercises overlapping database handlers in Live and Static modes, typed errors after suspension, independent HTTP/2 multiplexing, automatic 404 and 500 responses, and Adaptive replacement while an old handler remains in flight.
Cancellation tests verify that unfinished database work cannot leak a connection back into the pool. Sanitizer builds cover the same ownership path, and the optimized suite proves the result through the actual HTTP reactor.
Real service capacity will still depend on query cost, database placement, schema, pool size and topology. What changed in Gray is the architecture: one waiting query no longer owns the HTTP reactor.
", "image": "https://grayworth.com/news/media/gray-postgresql-continuations-16x9.png", "banner_image": "https://grayworth.com/og-news-gray-postgresql-continuations.png", "date_published": "2026-07-26T09:40:00Z", "date_modified": "2026-07-26T13:00:00Z", "authors": [ { "name": "Grayworth Engineering", "url": "https://grayworth.com/company" } ], "tags": [ "Runtime", "Gray PostgreSQL", "nonblocking database", "compiler continuation", "libpq", "HTTP server" ], "language": "en-US", "_grayworth": { "markdown_url": "https://grayworth.com/news/gray-postgresql-continuations.md", "word_count": 399, "reading_time_minutes": 2 } }, { "id": "https://grayworth.com/news/gray-native-loop-jit", "url": "https://grayworth.com/news/gray-native-loop-jit", "title": "Gray native loops reach 25.918× VM speedup", "summary": "Gray's bounded x86-64 backend lowered a 100-million-iteration typed loop to native code while retaining cooperative cancellation safepoints.", "content_text": "The same 100-million-iteration sum ran in a 210.511 ms median with native lowering and 5,456.099 ms with the Gray JIT disabled.\n\nGray’s x86-64 backend can lower typed loops, local mutation, integer comparisons and control flow into machine code through the documented native runtime ABI. Unsupported functions continue through verified VM fallback.\n\nThe backend does not accept a loop merely because it can encode a backward branch. Every generated backedge calls the runtime’s stop-token safepoint and returns a structured cancellation exit when work should stop.\n\nThat contract keeps native execution inside Gray’s structured task model. A hot loop can lose bytecode dispatch without becoming an uninterruptible island inside the process.\n\nThe diagnostic computed an identical 100-million-iteration integer sum in fresh, CPU-pinned Gray processes. One policy enabled native lowering; the other disabled the JIT and executed the same function through the VM.\n\nSeven accepted samples produced a 210.511 ms native median and a 5,456.099 ms VM median. Dividing those medians yields a 25.918× end-to-end improvement for this workload.\n\nThe measurement includes a stop-token safepoint on every loop backedge. The reported gain therefore includes the cost of retaining cancellation rather than benchmarking an unsafe stripped-down loop.\n\nA dedicated test starts a typed loop with a nine-quintillion-iteration ceiling, waits 20 milliseconds, requests cancellation and requires a CancelledError. The test passes with native lowering enabled and with interpreter-only execution.\n\nLive JIT, Live VM, Static JIT and Static VM produce the same result. ASan and UBSan builds exercise native relocation, generated frames, structured exits and the spawned-loop cancellation path.\n\nThe runtime ABI identifies exit kind, ABI version, source function and instruction. Native calls therefore preserve source-located errors and cancellation identity as execution returns to the VM.\n\nThis is a Gray-native-versus-Gray-VM diagnostic. It does not compare Gray with C++, Rust, Go or another compiler, and it does not claim that every Gray application becomes 25.918 times faster.\n\nThe result demonstrates that VM dispatch was the dominant cost in an eligible sustained loop and that Gray’s backend can remove it without changing the cancellation contract.\n\nBroader value lowering, more native call paths and additional platform backends remain active compiler work. Each expansion keeps the same differential rule: native execution must match the VM before its speed is accepted.", "content_html": "The same 100-million-iteration sum ran in a 210.511 ms median with native lowering and 5,456.099 ms with the Gray JIT disabled.
Gray’s x86-64 backend can lower typed loops, local mutation, integer comparisons and control flow into machine code through the documented native runtime ABI. Unsupported functions continue through verified VM fallback.
The backend does not accept a loop merely because it can encode a backward branch. Every generated backedge calls the runtime’s stop-token safepoint and returns a structured cancellation exit when work should stop.
That contract keeps native execution inside Gray’s structured task model. A hot loop can lose bytecode dispatch without becoming an uninterruptible island inside the process.
The diagnostic computed an identical 100-million-iteration integer sum in fresh, CPU-pinned Gray processes. One policy enabled native lowering; the other disabled the JIT and executed the same function through the VM.
Seven accepted samples produced a 210.511 ms native median and a 5,456.099 ms VM median. Dividing those medians yields a 25.918× end-to-end improvement for this workload.
The measurement includes a stop-token safepoint on every loop backedge. The reported gain therefore includes the cost of retaining cancellation rather than benchmarking an unsafe stripped-down loop.
A dedicated test starts a typed loop with a nine-quintillion-iteration ceiling, waits 20 milliseconds, requests cancellation and requires a CancelledError. The test passes with native lowering enabled and with interpreter-only execution.
Live JIT, Live VM, Static JIT and Static VM produce the same result. ASan and UBSan builds exercise native relocation, generated frames, structured exits and the spawned-loop cancellation path.
The runtime ABI identifies exit kind, ABI version, source function and instruction. Native calls therefore preserve source-located errors and cancellation identity as execution returns to the VM.
This is a Gray-native-versus-Gray-VM diagnostic. It does not compare Gray with C++, Rust, Go or another compiler, and it does not claim that every Gray application becomes 25.918 times faster.
The result demonstrates that VM dispatch was the dominant cost in an eligible sustained loop and that Gray’s backend can remove it without changing the cancellation contract.
Broader value lowering, more native call paths and additional platform backends remain active compiler work. Each expansion keeps the same differential rule: native execution must match the VM before its speed is accepted.
", "image": "https://grayworth.com/news/media/gray-native-loop-jit-16x9.png", "banner_image": "https://grayworth.com/og-news-gray-native-loop-jit.png", "date_published": "2026-07-26T10:00:00Z", "date_modified": "2026-07-26T13:00:00Z", "authors": [ { "name": "Grayworth Engineering", "url": "https://grayworth.com/company" } ], "tags": [ "Compiler", "Gray JIT", "native code", "x86-64", "virtual machine", "compiler benchmark" ], "language": "en-US", "_grayworth": { "markdown_url": "https://grayworth.com/news/gray-native-loop-jit.md", "word_count": 370, "reading_time_minutes": 2 } } ] }