You spin up new services, every team wants its own schema, and suddenly your database looks like a demolition derby. Now someone drops the word “Cortex” in standup, claiming it’s the way to manage observability and access across your CockroachDB clusters. You nod. Then quietly Google it. Welcome. You’re in the right place.
At its core, CockroachDB is a distributed SQL database built to scale horizontally with strong consistency and survival instincts that shame most clusters. Cortex, meanwhile, is an open-source project for multi-tenant, horizontally scalable time series storage. It’s the backbone behind metrics systems that don’t crumble when teams ship twice a day. When you connect CockroachDB with Cortex, you get a durable, queryable foundation beneath your observability pipeline.
The integration works like this: CockroachDB stores structured metadata, configurations, and long-term reference data. Cortex ingests and serves time series metrics from Prometheus or another scrape target. Linking them gives you one control plane for both configuration and telemetry. Your ops team no longer flips between dashboards and SQL consoles. You can correlate live metrics against the underlying data model in seconds.
Setting this up properly means thinking about identity and data flow. Cortex tenants map neatly to CockroachDB users or roles. You can reuse federation from Okta or AWS IAM via OIDC. The trick is to keep RBAC symmetric: roles in CockroachDB reflect the same permissions defined in Cortex. That symmetry makes automation easy and audit logs predictable.
A quick rule of thumb: metric data goes to Cortex, transactional or reference data goes to CockroachDB. The magic happens when both speak the same identity language.