The Provider Model

The Solanica Platform (and the open-source OpenEverest project it is built on) uses a small set of concepts shared across every database technology. Understanding them makes the MSSQL Provider easy to reason about.

Concepts

Concept	What it is	In the MSSQL Provider
Provider	A plugin that manages one database technology and implements the platform's provider interface (validate, sync, status, cleanup).	mssql
Component	A logical part of the database (engine, proxy, ...). Each has a type that resolves to a versioned container image.	engine → type mssql
Topology	A deployment shape combining components with an HA strategy and a user-facing form.	standalone, availabilityGroup
Version	A curated bundle of component versions known to work together.	2019, 2022, 2025
Backup Class	Declares how backups run and whether point-in-time recovery is supported.	mssql-native
Instance	The user-facing resource that ties it all together.	kind: Instance

The Instance resource

Users declare an Instance in the core.openeverest.io/v1alpha1 API group. It references the provider, picks a version and topology, and configures the engine component:

apiVersion: core.openeverest.io/v1alpha1
kind: Instance
metadata:
  name: my-database
spec:
  providerRef:
    name: mssql
  version: "2022"
  topology:
    type: standalone
  components:
    engine:
      replicas: 1
      storage:
        size: 10Gi
      parameters:
        edition: Developer

From Instance to SQL Server

The provider validates the Instance against the chosen topology's schema (for example, an Availability Group requires at least two replicas and a non-Express edition), then creates the matching MSSQL Operator resource. The operator provisions and reconciles the actual SQL Server pods.

Where to next

• Topologies — choose a deployment shape.
• Versions — supported SQL Server versions.
• Instance reference — the full spec.