Today, I'm excited to announce the release of the GizmoSQL Kubernetes Operator! GizmoSQL is a project started by a friend of mine, Phillip Moore, intending to reduce the operational cost of running large-scale SQL queries. GizmoSQL is already proven to be an invaluable tool for customers, saving them 90% of operational expenses compared to leading cloud data engines.

A Kubernetes Operator is a way to extend the Kubernetes API to create, configure, and manage applications on top of Kubernetes. Those who have used Kubernetes before are likely familiar with the concepts of Deployment, StatefulSet, or Job. Operators, alongside Custom Resource Definitions (CRDs), are a way to extend the Kubernetes API to create your own resources and manage them through it.

If you've used tools like Cert-Manager to manage TLS certificates in your cluster, you've already used a Kubernetes Operator. Numerous other third-party operators are available for Kubernetes, such as a Spark Operator and Postgres Operator for managing PostgreSQL clusters. The GizmoSQL Operator introduces the GizmoSQL CRD to the Kubernetes API, allowing users to manage and configure multiple GizmoSQL servers with ease.

For example, a user may be running a nightly job processing a large amount of data. With varying amounts of data, the job may exceed its allocated resources, perhaps even exhausting its specified CPU and memory limits. While Kubernetes provides resource requests and limits, it does not offer a way to adjust limits when a process runs out of memory dynamically. With an operator, we can introduce a mechanism to increase limits by a percentage if a process runs out of memory and crashes. We can even introduce a notion of increasing memory limits by percentage on pod crash or restart. Mechanisms like this are critical for avoiding hiccups in complex data processing infrastructure.

Whenever the topic of Kubernetes Operators comes up, the discussion always comes up: why not use Helm? While Helm is an excellent tool for installing Kubernetes resources, it is not a controller. Helm charts are a declarative way to install and manage Kubernetes resources. They are not designed to react to events or conditions that occur after the resource is created. You can think of Helm as a static tool, while an operator is a dynamic tool for managing the lifecycle of a resource.

The first step is to install the GizmoSQL Operator. You can use the Helm chart to install the operator

helm upgrade --install gizmosql-operator oci://registry-1.docker.io/gizmodata/gizmosql-operator-chart --namespace gizmosql-system --create-namespace

This will install the GizmoSQL Operator in your Kubernetes cluster in the gizmosql-system namespace. After the operator is installed, you can create a GizmoSQL cluster by applying the following manifest

apiVersion: gizmodata.com/v1alpha1
kind: GizmoSQLServer
metadata:
  name: example-gizmosql
  namespace: default
spec:
  resources:
    limits:
      cpu: "1"
      memory: "2Gi"
    requests:
      cpu: "500m"
      memory: "1Gi"

This will create a GizmoSQL cluster in your Kubernetes cluster in the default namespace. You can check the resource's creation by getting the YAML output.

kubectl get gizmosqlservers.gizmodata.com -ndefault -oyaml
apiVersion: v1
items:
- apiVersion: gizmodata.com/v1alpha1
  kind: GizmoSQLServer
  metadata:
    creationTimestamp: "2025-12-19T02:22:13Z"
    finalizers:
    - gizmodata.com/finalizer
    generation: 2
    name: example-gizmosql
    namespace: default
  spec:
    auth:
      secretRef: {}
    image: {}
    resources:
      limits:
        cpu: "1"
        memory: 2Gi
      requests:
        cpu: 500m
        memory: 1Gi
  status:
    conditions:
    - lastTransitionTime: "2025-12-19T02:22:13Z"
      message: StatefulSet for custom resource example-gizmosql created successfully
      reason: Reconciling
      status: "True"
      type: Available
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

A StatefulSet and Service are created for the GizmoSQL server. You can see the details of the StatefulSet and Service by getting the YAML output.

kubectl get pod -ndefault
NAME                 READY   STATUS    RESTARTS   AGE
example-gizmosql-0   1/1     Running   0          11h

kubectl get service example-gizmosql -ndefault
NAME               TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
example-gizmosql   ClusterIP   10.43.173.90   <none>        31337/TCP   11h

You can now connect to the GizmoSQL server within Kubernetes using the service name and port, or by port-forwarding the service to your local machine.