SQL LRS Is Widely Adopted. Now Let’s Talk About What That Means.

Over the past several years, SQL LRS has grown from an internal initiative in running xAPI in SQL environments into widely adopted infrastructure.

Today, it is deployed across government, defense, higher education, and enterprise environments and integrated into production data pipelines. It has been pulled over 100,000 times via Docker Hub and is used to support real-world learning, training, and analytics systems at scale.

We’re proud of that. And we’re grateful to the global community that has adopted and extended the software.

But there’s something we need to say plainly.

SQL LRS is no longer just a project. It is infrastructure.

And that shift has implications.

The Reality of Running SQL LRS in Production

Many organizations today are running SQL LRS in production environments.

That means it is collecting and processing mission-critical data, feeding downstream analytics and reporting systems, and supporting compliance, certification, and operational decision-making.

In other words, SQL LRS is not a side tool. It is part of the system of record.

At the same time, many of these deployments are operating without a formal support relationship.

That creates a gap. And it’s one that’s easy to overlook until it matters.

What “Open Source” Does—and Does Not—Guarantee

SQL LRS is open source under the Apache 2.0 license. That means you can use it freely, you can deploy it anywhere, and you can modify it to meet your needs.

But open source does not guarantee:

• Security patch timelines

• Compatibility with evolving platforms and standards

• SLA-backed support or incident response

• Ongoing certification and DevSecOps alignment (including in DoD contexts)

• Continuity of roadmap development

Those things don’t emerge automatically from adoption. They require sustained engineering effort.

The Stewardship Layer

SQL LRS does not maintain itself.

It is actively developed, maintained, and supported by the team at Yet Analytics—the same team that contributes to the IEEE stewardship of the Total Learning Architecture and the continuing evolution of xAPI as an IEEE and ISO global standard, has institutional knowledge of xAPI in government and high security contexts through our years of work supporting Advanced Distributed Learning (ADL) initiatives, has years of experience maintaining certification pathways and compliance alignment with DevSecOps including in cATO DoD contexts, and that has built and tested integrations across the ecosystem—including interconnectedness with learning metadata, machine-readable competency models, and enterprise learner records.

This work represents institutional knowledge that is not easily replicated.

As adoption grows, so does the responsibility to maintain the system in a way that meets the expectations of production environments.

The Risk of Unsupported Production Use

If SQL LRS is part of your production infrastructure, it’s worth asking a straightforward question:

What is your plan for maintaining it over time?

Running without a support agreement means your organization is assuming responsibility for monitoring and applying security updates, troubleshooting incidents and performance issues, managing upgrades and compatibility changes, interpreting and implementing evolving xAPI standards (particularly with regard to the still-in-standards-activity-mode xAPI Profiles), and maintaining alignment with certification requirements.

For some organizations, that may be a deliberate choice.

For many, it’s simply an unexamined assumption.

Consider that SQL LRS’s codebase is written in Clojure. Then assess whether you have an institutional knowledge of the Clojure programming language and ecosystem, as well as xAPI and its interdependencies with the IEEE LTSC portfolio suite of related TLA data standards, that would be necessary to support SQL LRS if something goes wrong or when dependencies needs to be updated and maintained.

Why Support Agreements Exist

Support agreements are not about restricting access to open source software.

They are how organizations ensure that the systems they depend on remain secure, stable, and compliant while remaining actively maintained.

For SQL LRS specifically, supported deployments provide direct access to the core maintainers, SLA-backed support and response, priority fixes and guidance, assistance with upgrades and integrations, and a voice in the product’s roadmap direction.

In environments where learning and training data is tied to operational outcomes, these are not “nice to have” capabilities—they are part of responsible system ownership.

Getting Started: Practical Paths to Support

We recognize that not every organization is ready to move immediately into a full support agreement.

In many cases, the right first step is a more focused engagement—one that helps you assess your current deployment, reduce risk, and plan for long-term sustainability.

To support that, Yet Analytics offers several low-friction entry points:

• Production Readiness Review
  A one-time engagement to evaluate your current SQL LRS deployment, identify risks, and provide actionable recommendations for stability, performance, and compliance.

• Annual Assurance Plan
  A structured, ongoing review model that ensures your deployment remains aligned with evolving standards, platform dependencies, and operational requirements.

• Security & Compliance Package
  Targeted support focused on security posture, patching strategy, and alignment with relevant certification or regulatory environments.

These options are designed to meet organizations where they are—providing immediate value while establishing a clear path toward long-term support.

For many teams, they serve as a practical first step toward ensuring that SQL LRS is not only deployed, but responsibly maintained.

A Note on Sustainability

Sustaining SQL LRS as a secure, certified, and evolving system requires ongoing investment in engineering, testing, and support.

As adoption increases, so does the scope of that responsibility. For example, we have recently added MySQL and MariaDB support to our longstanding Postgres and SQLite database options. And we support core environments from AWS to Azure to Google Cloud—as well as unique offline, on-prem, and mobile-deployed installs. All of those capabilities require a knowledge base and a team of maintainers to support enterprise and federated deployments. 

Additionally, we see more integrations—and not just more web apps. We’ve released open source publishing capabilities for Unity. We wrote an xAPI Profile to broker AI data from the Generalized Intelligent Framework for Tutoring (GIFT). And xAPI is emitted from 4th generation AI-enabled simulation software such as developed by Mixta. These integrations can be complicated to manage—especially as we see the ongoing expansion of compliance contexts and more expectations for reliability and performance.

Support agreements are the mechanism that allows that work to continue at the level required by production use.

Guidance for Organizations Using SQL LRS

SQL LRS will remain open source and freely available, distributed under the Apache 2.0 license.

At the same time, we offer the following guidance:

• For evaluation, research, and development use, SQL LRS is well-suited for deployment in its community-supported form

• For production deployments—especially in regulated, enterprise, or mission-critical environments—we strongly recommend establishing a support agreement

This ensures that your organization is not operating alone when it comes to maintaining a critical part of your data infrastructure.

Moving Forward

We’re committed to continuing to develop and support SQL LRS as part of the broader learning engineering ecosystem both for researchers and project developers as well as for enterprise deployment.

If your organization is currently running SQL LRS in production, we’d welcome a conversation about how to ensure long-term stability and security, align with certification and compliance requirements, and support your specific integration and data needs.

Because at this point, SQL LRS isn’t just software you can run. It’s infrastructure you rely on.

And infrastructure deserves support.