Over the past three years of building the industry’s best GraphQL caching service, we have spoken with hundreds of companies using GraphQL at a large scale. Through these conversations, we identified some common pain points with operating at that enterprise level.
This week, we’re launching a set of new features to solve some of the pain points of operating GraphQL at a large scale.
For the first time since launching our product, we are also increasing our prices to match the maturation of our product suite (our price had stayed unchanged for three years of constant improvement!) You can read more about that below.
Metrics and Schema Insights
Two of GraphQL’s core strengths are the ability for clients to specify exactly which fields they need and the ability to evolve APIs without versions.
These same strengths also come with their own tradeoffs. Giving up control over which fields to return to the client can make performance problems difficult to keep in check. A lack of explicit versions can make it difficult to understand how a schema has evolved over time.
Our new insights are aimed at eliminating that friction
New! Schema Insights, Versions, and Explorer are here to help you understand & explore your graph, past and present - what’s used, what isn’t, and how each type and field is performing. Learn More
New! Server Insights provide an expanded suite of metrics to help you understand server performance and errors, all via our out-of-the-box plugins or API. Learn More
Partial Query Caching General Availability
Since introducing Partial Query Caching five months ago, it has become easier for organizations to maximize what is cacheable, increasing stability, improving uptime, and lowering costs.
Today, Partial Query Caching is Generally Available and enabled by default on all new services. Learn more.
Rate Limiting General Availability
Stellate Rate Limiting is also entering GA today. It provides the flexibly to rate limit only certain mutations, certain queries with specific fields, certain customers on different pricing plans, and anything else that you might need to control. Learn More.
Edge Security
GraphQL’s dynamic nature is great for flexibility, but it expands the potential attack surface area if left unaccounted for.
To secure the most common attack avenues, we’re introducing controls for directives limits, alias count, query size, and suggestion masking. The request validation occurs in our edge service, meaning malicious requests never reach your network. Learn More.
Persisted Operations Registry
Often a TODO, rarely a TODONE, Persisted Operations (POs) are the most effective way to secure private GraphQL APIs by strictly limiting the operations clients can perform in production. This gives your developers the full flexibility benefit of GraphQL while locking down that attack surface area in production.
Our CLI-driven Persisted Operation (PO) registry provides a workflow for simultaneously using POs and edge caching. It also includes usage metrics and can optionally unfurl hashed queries before they’re sent to your origin. Learn More
Increasing prices
To cut to the chase, we’re increasing our prices. Here’s why:
Despite significantly improving our edge caching product over the past three years (including Partial Query Caching, CacheGuard, Directives, Errors, Custom Attributes, Dynamic Scopes, and more) and introducing entirely new products - Metrics and Rate Limiting - we have never raised our prices since the initial launch almost three years ago.
Fundamentally, what we are charging no longer aligns with the value we provide. Our customers have confirmed this: more than a dozen proactively mentioned wanting to pay us more.
We also have had a single price for everything, despite most of our customers picking and choosing the features and products from our buffet of offerings (now expanded even further) that match their needs best.
Pricing Changes
We are changing our list price, i.e., the price that self-serve customers pay that you can see on our website.
In the coming weeks, we will be reaching out to affected customers directly with specific pricing impacts.
This change does not affect enterprise contracts. We will have a conversation with our enterprise customers at the next renewal.
Moving forward, new signups will use the new pricing once their trial ends
The big change is that we will be charging independently for GraphQL Metrics, Caching, and Rate Limiting.
Metrics are $10/1M requests
Requests that contain cacheable fields or types are an additional $5/1M requests
Requests evaluated for rate limiting are an additional $5/1M requests
The Business plan will include a minimum spend of $249, which comes with 25 million metrics requests
The free plan will be limited to 100k requests per month. For requests above 100k, they will merely pass through our gateway.
Our previous “unlimited free plan” was intended to allow individual developers to use Stellate for side projects without worrying about how many requests they serve.
However, we have found that many businesses that make money use Stellate on the free plan! More often than not, we think that they don’t even know that this isn’t the intent of our free plan.
We still strongly believe in supporting developers and open source projects; even Stellate started as a side project. So, if you’re a developer with an OSS project or otherwise side project that is using and loving Stellate, please contact our support team.
On May 1st, all free and self-service users will be moved to the new pricing. We understand you might need more time if you want to migrate away from Stellate. If so, please email our CEO at max@stellate.co, and we’ll work with you to figure out a timeline.
We also know pricing is notoriously difficult to get right, so we’d love to hear your feedback to see what we could improve with our next iteration. Let our CEO know at max@stellate.co what you think.
Let’s Chat
We want to hear what you’re up to - how are you trying to level-up with GraphQL and how we can help? Please reach out to hello@stellate.co so we can connect, grow, and learn from each other.