Removal of Q# from the FORQ Ecosystem

Author: Noam Kloos — noam@noam.nl
Date: 11 July 2026

1. Introduction

This document explains why Q# has been permanently removed from the FORQ ecosystem and replaced by a combination of OpenQASM and Qizbit, in conjunction with PostgreSQL and an HPC toolchain based on Fortran and C. The focus is on technical, architectural and licensing constraints of Q#, and on the advantages of the chosen alternatives in an open-source setting.

2. Status of Q# and the modern QDK

Q# has evolved from a locally installable language and runtime into a cloud-centered component within the modern Quantum Development Kit (QDK). The classic QDK and its research libraries have been deprecated and moved to archival status, while new development is explicitly directed toward the modern QDK and Azure Quantum.

In practice, the modern QDK:

• ties Q# closely to Azure Quantum services;
• does not provide a standalone, production-grade local runtime;
• is not designed as an open, vendor-neutral infrastructure;
• operates under licensing conditions that constrain commercial use outside Azure.

As a result, Q# is not suitable as a core component in an open, Linux-based ecosystem such as FORQ.

3. Limitations of Q# for FORQ

For FORQ, the following limitations of Q# are decisive:

• No local server on Linux: there is no supported way to run a Q# server or runtime independently on Linux;
• Cloud dependency: execution and resource estimation are primarily positioned via Azure Quantum;
• Licensing and distribution constraints: classic QDK components are deprecated and subject to non-commercial licensing;
• Integration limitations: there is no stable C ABI for direct integration with Ada or Fortran, and no natural coupling to PostgreSQL as a central decision layer.

These properties conflict with FORQ’s design goals: openness, portability, Linux-native execution and direct integration with existing HPC languages and databases.

4. Migration to OpenQASM and Qizbit

To bypass the limitations of Q#, FORQ has migrated to a combination of OpenQASM and Qizbit as quantum IR and transport layer.

4.1 OpenQASM

OpenQASM is an open, widely supported description language for quantum circuits, used by multiple quantum platforms and tooling stacks. Within FORQ, OpenQASM serves as:

• an exchange format between different quantum backends;
• a basis for interoperability with external simulators and hardware;
• a neutral layer without vendor lock-in.

4.2 Qizbit

Qizbit is an internal, domain-specific quantum IR that:

• is fully under control of the FORQ ecosystem;
• integrates directly with Ada analysis and Fortran HPC routines;
• is easy to serialize into PostgreSQL for storage and decision-making;
• has no dependency on closed cloud services.

Qizbit enables modelling, scheduling and evaluation of quantum jobs without constraints imposed by external licenses or infrastructure.

5. PostgreSQL instead of Microsoft SQL Server

FORQ uses PostgreSQL as its central database and decision layer. The choice against Microsoft SQL Server is based on:

• Open-source nature: PostgreSQL is freely available and widely supported;
• C ABI: PostgreSQL provides a stable C interface, enabling integration with Ada and Fortran via ISO_C_BINDING;
• Linux-native: PostgreSQL runs directly and efficiently on Linux, without extra layers;
• HPC suitability: the database is well suited for storing analysis artefacts, runtime profiles and quantum results.

Microsoft SQL Server lacks a comparable C ABI and fits poorly into an Ada/Fortran-oriented HPC environment.

6. HPC toolchain on Linux and Windows

FORQ adopts a dual-platform strategy with a consistent HPC toolchain.

6.1 Windows

On Windows, FORQ is developed and prototyped with:

• IFX for Fortran;
• ICX for C;
• ML64 for assembler;
• PowerShell for build automation.

6.2 Linux

On Linux, the production and distribution layer runs with:

• ICX for C;
• IFX (optional) for Fortran;
• NASM/YASM for assembler;
• GNAT for Ada;
• PostgreSQL for decision-making;
• Qizbit and OpenQASM for quantum transport.

This combination yields a transparent, flexible and open system that supports both classical HPC and quantum extensions.

7. Conclusion

Q# has been removed from FORQ due to its cloud dependency, licensing and distribution constraints, lack of Linux-native execution and limited integration capabilities with Ada, Fortran and PostgreSQL. The migration to OpenQASM and Qizbit, combined with an HPC toolchain based on Intel Fortran and C and PostgreSQL as central database, results in a transparent, flexible and open ecosystem that better aligns with the goals of FORQ.