Nullability by default and versionless evolution

GraphQL takes a strong opinion on avoiding versioning: because the server only returns data that was explicitly requested, new capabilities can be added as new types or new fields on existing types without a breaking change, which has led to the common practice of serving a versionless, continuously evolving API. Nullability follows the same resilience logic — in a GraphQL type system every field is nullable by default, because a networked service backed by databases and other services has many failure modes: a database could go down, an asynchronous action could fail, an exception could be thrown, or granular authorization could deny a single field. Defaulting to nullable means any of these result in just that field returning null rather than a complete failure of the request. Non-null variants make the opposite guarantee — the field will never return null — and if an error does occur, the previous parent field becomes null instead. When designing a schema, decide whether null is an appropriate value for a failed field; typically it is, and where it is not, use non-null types. Scope: GraphQL. Reviewed October 4, 2026.