# Stargate puts REST, GraphQL and CQL in front of one Cassandra cluster

> Stargate is a Java data gateway that sits between client applications and a Cassandra cluster, exposing the same data over HTTP APIs, gRPC and CQL through independently scalable services, and its per-version persistence modules are the part that ties it to Cassandra.

**stargate/stargate** — An open source data gateway

- Repository: https://github.com/stargate/stargate
- Website: https://stargate.io
- Stars: 851 · Forks: 170
- Language: Java
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/stargate-stargate

## A gateway that exists to serve several protocols over one dataset

Stargate is described as an open source data API gateway, deployed between client applications and a Cassandra database. The motivation given in the README is fatigue rather than performance: the authors were tired of using different databases and different APIs depending on the work at hand, and of the read the manual and lengthy selection process that came with every new project. The answer they built is a framework that can serve many APIs for a range of workloads, with plugin support for new APIs, data types and access methods, including secondary database models, and with extensibility treated as a first class concern. The audience is a team that has already chosen Cassandra and wants the client protocol to be a deployment decision rather than an application architecture decision.

## The API services are separate deployments, not routes in one process

The most consequential structural choice is that the APIs are independently deployable microservices rather than endpoints inside the coordinator. The apis/ directory holds sgv2-restapi, which exposes Cassandra data over REST, sgv2-graphqlapi, which does the same over GraphQL, and sgv2-docsapi, which serves a document API, with sgv2-quarkus-common providing shared utilities for the Java and Quarkus based services. Each API service carries its own integration test suite that runs it against the coordinator and the supported backends. The operator-facing consequence, stated in the README, is that storage nodes, API service nodes and coordinator nodes in a Cassandra cluster can be deployed and scaled independently. That is the argument for the whole project: the API tier scales on request volume while the storage tier scales on data, and neither change forces a redeploy of the other.

## The coordinator is a non data storing node that speaks gRPC and CQL

The coordinator modules sit in a separate directory and describe the node that clients talk to. Coordinator nodes join the backing Cassandra cluster as non-data-storing nodes, which the README says enables them to read and write data more efficiently, and they can be scaled independently of the data nodes. The module breakdown is worth reading because it shows the layering. The cql module implements the Cassandra Query Language interface, the grpc module is a fast CQL over gRPC implementation described as the HTTP-based interface equivalent to CQL performance, the bridge module is the gRPC interface the API services use, health-checker exposes HTTP endpoints for health checking, metrics-jersey collects metrics for the node and its interfaces, and stargate-starter is the main Java application started through the `starctl` script. So a client that already speaks CQL can skip the API services entirely, while a REST or GraphQL client goes through them.

## Persistence is a pluggable interface implemented once per Cassandra version

This is where the project is most tightly bound to its storage engine, and the module names make the cost explicit. There is a persistence-api interface for working with persistence services, persistence-common for the shared utilities, and then one implementation per database version: persistence-cassandra-3.11, persistence-cassandra-4.0 and persistence-dse-6.8 for DataStax Enterprise. The README describes the responsibilities of a persistence implementation as handling and converting requests to database queries, dispatching to a specific version of Cassandra, and returning and serving responses, and the 3.11 module notes that it joins the cluster as a coordinator-only node, mocks the Cassandra system tables for native driver integration, executes requests using the Cassandra QueryHandler and QueryProcessor, and converts internal Cassandra objects and ResultSets into Stargate datastore objects. A module per version means the abstraction is real but not free, and adding support for a new storage engine is a substantial piece of work rather than a configuration change.

## Authentication is a pluggable interface with three shipped providers

The coordinator also supports a pluggable authentication and authorization approach, again split into an interface and implementations. The authnz module is the interface for working with auth providers, auth-api is a REST service for generating auth tokens, auth-table-based-service stores tokens in the database itself, and auth-jwt-service authenticates using externally generated JSON Web Tokens. The split between the two token services is the decision a deployer has to make. Storing tokens in the database keeps the system self-contained and revocable, while accepting external JWTs moves the signing authority outside Stargate and makes the service dependent on whatever issues those tokens. Neither the README nor the module list describes a third option, so a deployment that needs asymmetric signing with a specific key rotation policy is choosing the external JWT path.

## Getting it running means Docker, Helm or a development environment

The README points to three routes. For a desktop, the docker-compose instructions in the docker-compose/ directory bring Stargate up in front of a local Cassandra. For Kubernetes, there is a Helm chart in the helm/ directory that installs Stargate alongside an existing cluster, and the K8ssandra project is named as a distribution that packages Cassandra, Stargate and additional tooling together. For developers, the coordinator and apis directories each carry a README with instructions for setting up a development environment, and the DEV_GUIDE.md holds the instructions for running and extending the test suite. The repository is a monorepo with an apis/ directory, a coordinator/ directory, docker-compose/, helm/, assets/, and a .gitmodules file, so the subprojects are partly separate checkouts. The release process is visible too, with a .chglog/ directory, CHANGELOG.md, CHANGELOG_V1.md and an update_changelog.sh script, and the recent tags show both a stable line and a beta line, which is the pattern to watch if you plan to track a moving target.

## When a gateway is more machinery than the problem needs

The honest limitation is that Stargate is a distributed system to solve a data access problem, and most applications do not have that problem. If a service talks to one Cassandra cluster with the official driver, adding a coordinator, an API service and a bridge between them introduces network hops, an extra failure domain and a second place to look when a query misbehaves. The multi-version persistence modules compound this: the abstraction is designed to hide version differences, but a behaviour that differs between Cassandra 3.11, 4.0 and DSE 6.8 will surface through whichever persistence implementation you have enabled, and the module list gives no hint about which features are safe to use across all of them. There is also a narrower point about scale. Splitting the API tier from the storage tier is exactly what you want when API traffic and data size scale differently, and exactly what you do not need for a modest workload, where the coordination and operational overhead outweighs the benefit.

## Conclusion

Stargate suits a team that has committed to Cassandra as its storage and wants more than one client protocol over the same data without writing three access layers by hand, and it suits an operator who wants the API tier scaled separately from the storage cluster. It is the wrong tool for a polyglot data platform, because the current form of the project is specific to Apache Cassandra compatible backends, and it is the wrong tool for a small application, because running a coordinator plus an API service plus a storage cluster is a lot of moving parts for what a driver can do. Before adopting it, read the coordinator and APIs development environment instructions, and confirm that the persistence implementation for your exact Cassandra version is one you would maintain, since the modules are per-version. The last push was on 2026-10-16, and the release tags include v2.0.51 from 2026-06-16 alongside a v2.1.0 beta line.

## FAQ

### What is Stargate and where does it sit in an architecture?

Stargate is an open source data API gateway from the Stargate project, deployed between client applications and a Cassandra database. The README describes it as often sitting behind a load balancer or proxy and exposing HTTP APIs, gRPC and CQL to clients while the Cassandra cluster acts as the storage backend.

### Which APIs does Stargate expose over Cassandra?

The apis directory contains sgv2-restapi for exposing Cassandra data over REST, sgv2-graphqlapi for GraphQL, and sgv2-docsapi for a document API. The coordinator separately exposes the CQL interface and a gRPC implementation of it.

### Which Cassandra versions does Stargate support?

The persistence modules are implemented per version: persistence-cassandra-3.11, persistence-cassandra-4.0 and persistence-dse-6.8 for DataStax Enterprise. The README states that the current form of the project is specific to Apache Cassandra compatible backends.

### How do I run Stargate locally or on Kubernetes?

The README points to docker-compose instructions for a desktop, a Helm chart in the helm directory for installing Stargate alongside an existing Cassandra cluster in Kubernetes, and the K8ssandra project for a packaged distribution. Development environments for the coordinator and the APIs each have their own README.

### How does Stargate handle authentication?

Authentication and authorization are pluggable through the authnz interface, with a REST service for generating tokens, a table based service that stores tokens in the database, and a service that authenticates using externally generated JSON Web Tokens.

## Sources

- [License: Apache-2.0](https://github.com/stargate/stargate/blob/main/LICENSE)
- [Project website](https://stargate.io)
- [README](https://github.com/stargate/stargate/blob/main/README.md)
- [Releases](https://github.com/stargate/stargate/releases)
- [stargate/stargate on GitHub](https://github.com/stargate/stargate)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/stargate-stargate