Xata open sourced a Postgres platform built for Kubernetes. The README headline is copy-on-write branching, scale-to-zero, control-plane APIs, a SQL gateway, and CloudNativePG/OpenEBS under the hood.

The Go code is not a single neat library. It is platform code: service binaries, generated API types, Kubernetes custom resources, OpenAPI definitions, auth claims, observability wrappers, and command wiring. That makes it useful to read if you build Go services that operate infrastructure rather than just expose CRUD endpoints.

Services share a command shape

The internal command package gives each service the same basic CLI surface. A service is passed into a root command builder:

func RootCmdForService(svc service.Service) *cobra.Command {
	cmd := &cobra.Command{
		Use: svc.Name(),
		PersistentPreRunE: func(cmd *cobra.Command, args []string) error {
			return svc.Init(cmd.Context())
		},
		PersistentPostRunE: func(cmd *cobra.Command, args []string) error {
			return svc.Shutdown(cmd.Context())
		},
	}
	cmd.AddCommand(runCmd(svc), setupCmd(svc), versionCmd(svc))
	return cmd
}

That is a good pattern for a platform repo. Each binary can own its actual service logic while sharing run/setup/version behaviour. It also makes startup and shutdown visible in one place.

Observability wraps service execution

internal/cmd/o11y.go wraps command execution with logging, tracing, and metrics setup:

func WithO11y(ctx context.Context, name string, fn func(context.Context, *o11y.O) error) error {
	// initialize monitoring
	defer monitoring.Shutdown(context.Background())
	return fn(ctx, obs)
}

The detail worth stealing is the function shape. Instead of letting every service remember to initialize and close telemetry, pass the useful object into a callback and make shutdown part of the wrapper. That keeps the command body focused on the service.

Kubernetes resources are normal Go types

Xata defines Kubernetes custom resources in Go, such as ClusterPool:

type ClusterPoolSpec struct {
	Replicas int32 `json:"replicas,omitempty"`
}

type ClusterPoolStatus struct {
	AvailableReplicas int32 `json:"availableReplicas,omitempty"`
}

Those types generate the Kubernetes deepcopy methods and give controllers a typed API. If you have only written HTTP services in Go, Kubernetes operators are a useful shift in mindset: your API is not just JSON over HTTP, it is desired state stored in the Kubernetes API server.

Auth claims are kept small and explicit

The token package models the claims Xata needs:

type Claims struct {
	Subject       string         `json:"sub"`
	Email         string         `json:"email"`
	APIKey        string         `json:"api_key_id"`
	Organizations []Organization `json:"organizations"`
}

Methods such as UserID, UserEmail, APIKeyID, and HasAccessToOrganization keep authorization checks out of raw map access. This is minor code, but it matters. Auth data moves everywhere in a platform; typed helpers reduce copy-paste mistakes.

OpenAPI is part of the source tree

The openapi/ directory contains specs for gateway, projects, auth, and webhooks. Generated clients and server types are part of the normal development flow.

That is the right call for a multi-service control plane. The API contract should be versioned and reviewed next to the service code. In a platform like Xata, external API shape matters as much as internal package shape.

What to take from Xata

The useful Go lesson is how infrastructure products are assembled. Use shared command wrappers for service lifecycle. Put observability setup around execution rather than scattering it through every binary. Model auth claims as typed methods. Treat Kubernetes resources as Go APIs. Keep OpenAPI contracts in the repo.

The copy-on-write branching story is the product hook. The code worth studying is the control plane around it.