OOM from tsc using patched database types

[rainhead]

Describe the bug

Originally sindresorhus/type-fest#1271, but they seem to think it's not their problem.

When I create a client using a Database type that has been patched with SetNonNullDeep, if I have patched more than a few key paths, tsc runs out of memory when querying a table.

The playground takes a very long time, but does eventually typecheck.

Library affected

postgrest-js

Reproduction

playground

Steps to reproduce

Run tsc on the file from the playground. With a few keypaths run through SetNonNullableDeep it takes 5-10 seconds (!), with more it takes more than a minute or runs out of memory.

System Info

tsc --version
Version 5.9.3

  System:
    OS: macOS 26.0.1
    CPU: (8) arm64 Apple M1
    Memory: 258.70 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 24.10.0 - /opt/homebrew/bin/node
    Yarn: 1.22.22 - /Users/rainhead/.nvm/versions/node/v20.14.0/bin/yarn
    npm: 11.6.0 - /opt/homebrew/bin/npm
    pnpm: 10.18.2 - /opt/homebrew/bin/pnpm
    Deno: 2.1.10 - /opt/homebrew/bin/deno
  Browsers:
    Chrome: 141.0.7390.77
    Firefox: 143.0.4
    Safari: 26.0.1
  npmPackages:
    @supabase/auth-js: ^2.75.0 => 2.75.0 
    @supabase/sentry-js-integration: ^0.3.0 => 0.3.0 
    @supabase/supabase-js: ^2.75.0 => 2.75.0 
    supabase: ^2.51.0 => 2.51.0

Used Package Manager

npm

Logs

Click to expand!

time tsc repro.ts
tsc repro.ts  75.25s user 5.44s system 107% cpu 1:14.84 total

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Supabase JS Library issue and not an issue with the Supabase platform. If it's a Supabase platform related bug, it should likely be reported to supabase/supabase instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[avallete]

I can reproduce this on @supabase/supabase-js 2.75.0 and 2.74.0 (TS 5.9.3 on M1). Applying SetNonNullableDeep to the full Database makes tsc blow up on large schemas.

I also tried “prettifying” the result to collapse intersections—no improvement:

type PatchedDatabase = SetNonNullableDeep<
  Database,
  | "public.Views.occurrences.Row.id"
  | "public.Views.occurrences.Row.identifiers"
  | "public.Views.occurrences.Row.location"
  | "public.Views.occurrences.Row.location.lat"
  | "public.Views.occurrences.Row.location.lon"
  | "public.Views.occurrences.Row.observed_at"
  | "public.Views.occurrences.Row.photos"
  | "public.Views.occurrences.Row.taxon"
  | "public.Views.occurrences.Row.taxon.scientific_name"
>;
export type Prettify<T> = { [K in keyof T]: T[K] } & {};
type PrettifiedDatabase = Prettify<PatchedDatabase>;

Workaround: patch only the specific Row and merge it back instead of deep-patching the whole DB:

import { createClient } from "@supabase/supabase-js";
import type { MergeDeep, SetNonNullableDeep } from "type-fest";
import type { Database } from "./database.types";

type ModifiedDatabase = MergeDeep<
  Database,
  {
    public: {
      Views: {
        occurrences: {
          Row: SetNonNullableDeep<
            Database["public"]["Views"]["occurrences"]["Row"],
            | "id"
            | "identifiers"
            | "location"
            | "location.lat"
            | "location.lon"
            | "observed_at"
            | "photos"
            | "taxon"
            | "taxon.scientific_name"
          >;
        };
      };
    };
  }
>;

const client = createClient<ModifiedDatabase>("", "");

This one infer correctly in a reasonable time.

[rainhead]

Thanks!