Introduction

Help us grow — star us on GitHub<br>LinkedRecords

IntroductionGetting StartedCore Concepts<br>Facts and TriplesQuery LanguageTermsAuthorization ModelAccountabilityQuotasAttribute Types<br>Key-Value AttributesLong Text AttributesBlob AttributesPatterns<br>Blueprint PatternTeam PatternsQuery PatternsSharing PatternsReference<br>Configuration

Introduction<br>LinkedRecords - A Backend-as-a-Service for collaborative SaaS applications

What if writing a production-ready SaaS application is as easy as a React.js hello world tutorial?

What if you operate a SaaS on your infrastructure and your users could choose where their data lives - on their own infrastructure, in their own jurisdiction?

What if AI coding assistants couldn't accidentally create security holes because authorization is baked into every operation?

What if multiple apps could work with the same data without any integration work?

LinkedRecords makes all of this possible. It's not just another BaaS - it's a fundamentally different architecture for building collaborative applications.

LinkedRecords

LinkedRecords is a Backend-as-a-Service that you can connect to directly from your single-page application - no backend code required. Think of it as a database you can call directly from your React app, with authorization built in and real-time collaboration out of the box.

// Query data with facts - updates automatically when anything changes<br>const todos = useKeyValueAttributes([['$it', 'isA', 'Todo']]);

You can use any OpenID Connect provider (Auth0, Keycloak, etc.) for authentication, so you don't need to implement login flows. Authorization is built into the data model itself - when you create data, you specify who can access it. And real-time collaboration uses CRDT and Operational Transform, so concurrent edits merge instead of overwriting each other.

Not Local-First, But Server-Sovereign

If you've heard of local-first tools like Automerge, Yjs, or Replicache - LinkedRecords is different. The key distinction is where data lives and who enforces authorization.

AspectLocal-FirstLinkedRecordsData lives On the clientOn the serverWorks offline YesNoAuthorization Client-side or sync-layerServer-enforced

Choose local-first when users need to work offline or instant local response is critical.

Choose LinkedRecords when you need server-enforced authorization, central governance over data, the BYOB model where customers control their backend, or audit trails that require server-side logging.

The difference is conceptual: local-first optimizes for offline capability, while LinkedRecords optimizes for a server-authoritative state with built-in authorization - making it well suited for enterprise SaaS.

Cloud Sovereignty

Traditional SaaS has a problem: the vendor controls your data .

When you use a typical SaaS application, the vendor operates the complete stack - the frontend, the backend, and the database where your data lives. Your business data sits on infrastructure you don't control, in a jurisdiction you might not have chosen.

LinkedRecords enables a different model: Bring Your Own Backend (BYOB) .

┌─────────────────────────────────────────────────────────────┐<br>│ Traditional SaaS │<br>│ ┌─────────────────────────────────────────────────────┐ │<br>│ │ SaaS Vendor Infrastructure │ │<br>│ │ ┌─────────────┐ ┌─────────────────────────┐ │ │<br>│ │ │ Frontend │ + │ Backend + Your Data │ │ │<br>│ │ └─────────────┘ └─────────────────────────┘ │ │<br>│ └─────────────────────────────────────────────────────┘ │<br>└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐<br>│ LinkedRecords BYOB Model │<br>│ ┌──────────────────────┐ ┌──────────────────────────┐ │<br>│ │ SaaS Vendor │ │ Customer-Controlled │ │<br>│ │ ┌────────────────┐ │ │ ┌────────────────────┐ │ │<br>│ │ │ SPA via CDN │ │───▶│ │ LinkedRecords │ │ │<br>│ │ │ (frontend only)│ │ │ │ Backend + Data │ │ │<br>│ │ └────────────────┘ │ │ └────────────────────┘ │ │<br>│ └──────────────────────┘ └──────────────────────────┘ │<br>└─────────────────────────────────────────────────────────────┘

How it works:

SaaS vendors build their application as a single-page application

The frontend is distributed via CDN - just static files

When users open the application, the app can ask the user which LinkedRecords backend to use

All data is stored on the endpoint the user chose - data never leaves the customer's infrastructure

The SaaS vendor and the LinkedRecords provider never need to communicate - the API is intentionally minimalistic, providing just a few primitives (facts and attributes) that applications build upon. This minimal surface area is also the foundation for backwards compatibility: different versions of a SaaS application can work with different versions of LinkedRecords without coordination

Why this matters:

Data residency compliance - Keep data in your jurisdiction (GDPR, industry regulations)

No vendor lock-in - Your data is in a database you...