GraphQL error handling sucks. There, I said it.

Ever hunted through the errors list to figure out if a null was legit or caused by an error? If you're like me, you gave up and now treat nulls as "maybe errored, maybe absent, maybe both."

And nullability. Schema designers make anything that might fail nullable, producing partial responses when errors occur. But since anything can fail, now everything is nullable— and we're drowning in null checks. We recklessly cast to non-null or fall back to the empty string out of desperation. And we still don't know what's truly nullable.

No more.

This talk introduces a new, pragmatic approach, born from years of work by the Nullability WG. We propose a future where schemas reflect the true nullability of business entities, and error handling is where it belongs: in your code, not your data. Use your language's built-in tools to handle errors ergonomically; and drop the unnecessary null checks. When you read a null, it should mean one thing: the absence of data.

This isn't some distant ideal on the horizon of GraphQL's future; with just 512 bytes added to your GraphQL client, you can start adopting this today. Come see how.

This ad-hoc talk is just Benjie (and Michael Staib from ChilliCream!) riffing about some of the work that's going on in the GraphQL Working Groups currently. Topics covered include:

• GraphQL Spec Freeze July 2025 - a new spec cut is coming!
• Incremental Delivery
• Schema Coordinates
• Fragment Arguments
• Nullability
• Operation Descriptions
• Service Capabilities
• GraphQL-over-HTTP
• Partial Success Status Code
• Composite Schemas
• GraphQL.js v17
• GraphiQL v5
• OpenTelemetry
• Documentation Overhaul
• Community Working Group
• Website Redesign
• GET INVOLVED!

GraphQL has exploded in popularity since its public launch in 2015, and PostgreSQL is still going strong after almost 30 years of development, gaining market share and impressive features at an ever increasing rate.

These tools can pair beautifully, in particular because they're both strongly typed and declarative. In this talk, we'll learn how combining these two technologies can lead to massively increased software development and delivery speed, faster APIs, fewer bugs, and ultimately enable you to focus on delivering value on the frontend rather than maintaining three different layers of data models and associated logic on the backend (DB, application, API).