The SQL-first execution platform for recurring system work.
SQLX
SQLX keeps business orchestration in SQL Server while giving SQL developers the reach of .NET through CSML and a governed runtime model. It is built for workflows that begin and end in data but need APIs, files, documents, mailboxes, browser-driven steps, or other external reach in the middle. For firms, that makes recurring execution more visible, recoverable, and safer to change. For SQL-heavy teams, it means more of the workflow can stay inside one governed operating model instead of fragmenting into services, scripts, and side utilities.
SQL Server control plane • CSML language layer • out-of-process runtime • remote execution when needed • recurring system work • less scattered glue code
Lets SQL developers own workflows that usually force a separate application lifecycle
Gives firms a stronger operating layer for recurring execution they already depend on
Keeps orchestration in SQL Server while execution can run locally or remotely
Handles APIs, files, PDFs, mailboxes, browser-driven steps, and .NET behavior through CSML
Makes recurring operational glue more visible, reviewable, and recoverable
Built for SQL-heavy teams that want external reach without abandoning SQL-first workflows
Put business orchestration where business truth lives
Many real workflows begin in SQL Server, end in SQL Server, and still force teams to leave the database in the middle. A vendor API has to be called. A token has to be acquired or refreshed. A file has to be downloaded, transformed, uploaded, archived, or turned into a PDF. A mailbox has to be checked. A browser-driven portal step has to be automated because no stable API exposes it.
Without a governed model for that middle layer, firms end up depending on scripts, services, scheduled jobs, and one-off utilities that keep the work moving but make it harder to see, recover, and change safely later. SQLX exists for that class of problem.
The operating belief behind the product
Business orchestration should live where business truth is visible, queryable, and auditable. In operational systems, that place is usually the database. SQLX keeps orchestration there while letting execution happen where it belongs.
What SQLX actually is
For the firm
SQLX governs recurring execution the business depends on but rarely sees clearly. Jobs, vendor calls, scheduling, retries, recovery, permissions, and state movement become easier to standardize, trace, and operate after go-live.
For the SQL developer
SQLX expands what a SQL-heavy team can directly own. Instead of pushing every awkward middle step into another service or utility, developers can keep orchestration in SQL Server while reaching external systems, documents, content flows, and automation steps through one governed model.
SQL Server stays the control plane
Scheduling, permissions, orchestration, business state, and operational visibility remain centered in SQL Server.
CSML expresses executable behavior
CSML is the language layer for representing executable .NET behavior inside a SQL-centered operating model.
The runtime executes out of process
SQLX separates orchestration from execution so SQL decides what should happen and the runtime performs the external work.
Why that architecture matters
The gain is not just fewer lines of code. It is fewer tools, fewer deployments, fewer handoffs, and a much shorter path from need to working workflow. SQLX gives SQL developers the reach of .NET without forcing the workflow itself out of SQL Server, while giving the firm a stronger operating standard for recurring execution.
Centralize orchestration, not compute
SQLX is not arguing that every heavy operation should run on the main SQL Server. It is arguing something more useful: orchestration should stay centralized where the business can see it, while execution can happen locally, on another node, or through a redirected runtime path when that is the right operating choice.
One SQL contract
The runtime is called through a single SQL-side contract, which simplifies deployment and makes the platform easier to reason about.
Execution wherever it belongs
Work can execute locally or remotely without forcing orchestration out of SQL Server.
Thin app, stronger operating layer
Applications can stay focused on UX while the recurring system work lives in a more visible, governed, queryable model.
What SQLX governs
Jobs and scheduling
Recurring work stops depending on scattered timers, patched services, and private knowledge of when things are supposed to run.
Logging and traceability
Teams can see what ran, what returned, what failed, what changed, and which records or processes were affected.
Retries and recovery
When something breaks, recovery starts from visible logic instead of guesswork and side rescue sequences.
Permissions and controlled change
The layer carrying recurring work becomes safer to change because access and behavior are not being handled informally.
Why this becomes operational, not just technical
When recurring execution goes soft, visible workflow inherits the same doubt. A process still downloads the file, but the state update fails. A print batch is created, but nobody trusts which items completed. An attachment arrives, but the downstream document step does not finish. The work appears to move, yet nobody can say with confidence what happened, what changed, what is safe to retry, or what the correct recovery path is.
What firms and developers run through SQLX
SQLX is strongest when the beginning and end of the work are already database-centric, but the middle touches systems and capabilities SQL cannot handle alone.
API and authentication workflows
Call vendor APIs, acquire and refresh tokens, shape payloads, and move structured results back into SQL-driven workflows.
vendor API calls and token handling
read, write, update, and status operations
polling, batch monitoring, and retry paths
structured outputs returned into SQL Server
Documents, PDFs, and file movement
Handle downloads, uploads, file transforms, PDF generation, and file-drop processing between operational systems and document systems.
HTML-to-PDF and image-to-PDF generation
file upload, download, archive, and cleanup
XML and spreadsheet intake patterns
document routing into downstream systems
Mailbox, content, and message processing
Retrieve messages and attachments, convert external content into SQL-friendly forms, and keep downstream steps inside one governed workflow.
mailbox and attachment retrieval
HTML reshaping and content extraction
email-to-document workflows
operational handoffs into queues and tables
Browser-driven and hard-to-reach workflows
Some vendor tasks still require browser automation or portal interaction because no stable API exists. SQLX keeps that class of work closer to one governed model through CSML.
browser automation represented in CSML
portal-dependent retrieval or submission
recoverable execution around fragile vendor surfaces
less one-off implementation drift outside the model
The kinds of workflows that make SQLX feel real
SQLX is not starting from theory. The platform direction is grounded in the kinds of workflows SQL-heavy teams actually end up owning in live environments.
Move external system truth into SQL without building an app around it
A SQL developer wants all HubSpot Companies in a warehouse table. Without SQLX, that usually means building an application or service to call the API, manage pagination and authentication, parse results, load SQL, schedule the work, and monitor it. With SQLX, the retrieval becomes a callable SQL capability inside the workflow that already lives in SQL Server.
Handle web content, documents, and files in one governed flow
A workflow needs to fetch an image or webpage, reshape the content, generate a PDF, and save the result to disk or hand it off downstream. SQLX lets the SQL developer keep the operational flow intact while borrowing .NET only for the parts SQL cannot do alone.
Treat a folder or mailbox as a transient inbox, not the system of record
A vendor drops XML files into a folder. A mailbox receives HTML content and attachments that need to become governed documents. SQLX helps pull that outside-world content into structured, queryable, auditable SQL workflows early, instead of leaving the business dependent on side utilities forever.
Use browser automation when the vendor gives you no better path
Some recurring operational work still depends on browser-driven portals because there is no stable API. SQLX keeps even that awkward class of work inside a more visible and recoverable model instead of scattering it into fragile disconnected scripts.
Proven in real vendor ecosystems and real products
Operational ecosystems already touched by SQLX-class work
CCH Axcess
SafeSend
GoFileRoom and FirmFlow
signature surfaces such as DocuSign and Adobe Sign
mailbox and Microsoft Graph–style workflows
PDF, file, and document transformation workflows
Products already powered by the platform direction
Client Onboarding
Tax Dashboard
Financial Dashboard
Why that matters
SQLX is not a detached developer experiment. It is part of a serious product architecture. That matters because the strongest proof of a platform is not that it can call .NET, but that it can keep real recurring workflows visible, recoverable, and operationally usable after go-live.
Where SQLX fits best
The best fit is where the firm needs a governed execution layer and the development team wants SQL Server to stay the orchestration center.
Great fit when
SQL Server already acts as the operational data hub
the workflow begins and ends in data, but needs external reach in the middle
developers are tired of building small services around database-centric workflows
auditability, recoverability, and controlled change matter
the team wants one governed model instead of more scattered glue code
Not the first choice when
a vendor already provides a complete, reliable integration that fully solves the need
the problem is mainly a user-facing application with minimal orchestration or data movement
the workflow is isolated, one-off, and not worth standardizing
the team wants a general-purpose app framework rather than SQL-centered orchestration
How adoption usually starts
Start with one workflow that already hurts
Choose the recurring process that already depends on scripts, downloads, retries, credentials, file handling, vendor responses, or awkward recovery steps.
Standardize the operating pattern
Bring authentication, logging, scheduling, permissions, retries, and error handling into one repeatable model so the workflow stops depending on improvisation.
Expand once the trust model is proven
After the first workflow is visible and recoverable in production, move more integrations, jobs, and operational automations into the same SQLX model.
Why the lift does not have to fall on the buyer
This is where principal-led depth matters. We already understand SQL-centered orchestration, recurring execution, and the kinds of outside-world steps that make these workflows hard to trust later. That shortens the path from current-state pain to one governed model the firm and the developer can both operate with more confidence.
FAQ
Is SQLX mainly for SQL Server developers?
Yes. That is the center of gravity. SQLX expands what SQL-heavy teams can directly build and operate, even when the workflow needs .NET reach, external APIs, files, documents, or browser-driven automation.
Do I need to learn CSML to benefit from SQLX?
No. A developer or team can benefit from wrapper procedures and existing SQLX-backed capabilities without starting by writing CSML directly.
Is CSML the product story?
CSML matters, but it is not the whole story. The larger value is the architecture around it: SQL Server as control plane, governed execution patterns, and a runtime model that keeps external work connected to SQL-centered orchestration.
Does SQLX replace all .NET development?
No. SQLX is for the class of work where orchestration naturally belongs close to the database and the outside-world reach is part of an operational workflow, not a separate application for its own sake.
Does this mean everything has to run on the main SQL Server?
No. SQLX keeps orchestration in SQL while execution can happen locally or remotely. The point is to centralize orchestration, not compute.
Why not just build another service?
Because many of these workflows already start and end in SQL. Building a separate service often recreates scheduling, configuration, logging, monitoring, and recovery outside the place where the business workflow already lives.
What kinds of workflows are the best candidates?
Recurring workflows that touch APIs, documents, files, mailboxes, status movement, polling, reconciliation, routing, and cross-system operational handoffs are usually the strongest candidates.
Put recurring execution under a stronger standard without pulling orchestration away from SQL Server.
Start where the firm already depends on the workflow and where the development team is tired of carrying it through scattered scripts, services, and recovery knowledge no one wants to keep inheriting.