Should all extensions be managed in this repository? Or in nixpkgs?

[Austin Seipp]

Background

Currently, nix-postgres creates PostgreSQL distributions using the upstream Nix expressions as a source for PostgreSQL itself. That's good. But it uses extensions for PostgreSQL that come from two sources: the upstream nixpkgs repository, and also this repository.

The problem

Aside from the obvious fact we need to split up some code in flake.nix, what this means is that there may be multiple version updates upstream that occur with a single bump of the nixpkgs flake e.g. using nix flake update. This may not be totally desirable in some cases; for example you may want pg_net to upgrade to 0.7.2, but not upgrade something like timescaledb. That would mean you'd need to override timescaledb to be a previous version, or contribute changes upstream adding a separate version, et cetera.

Solution 1: Move everything upstream

The nice thing about this is that people will try to help you keep things maintained, and automated update robots will kick in and do things like point releases for you. That's good, but it also means you have to respond effectively to upstream changes. For example, if an extension author makes a change that breaks an upgrade — you want to catch that as soon as possible, and do integration testing against versions.

In practice, this means you need to track upstream nixpkgs pretty aggressively to catch failures. Whether or not this is a good idea I think is a matter of perspective; there's something to be said about embracing this approach and actively fixing things as they come up.

Solution 2: Move everything into this repository

The opposite approach from 1, this would effectively mean doing a cp -r on the extensions directory upstream, and moving everything we want to provide here. Then this repository is the single source of truth for everything.

I think there's some virtue to this approach because it's more "integrated" and aligned with what Supabase will provide for customers and users. You can ignore everything you don't provide, and everything is controlled here on a case-by-case basis; this means you have to do nix-update etc yourself (or write your own auto-update robot), but it does mean you have full control over the pipeline and extensions you offer to users at all times.

I think the amount of effort here is probably "sort of equivalent" to the effort in 1.

Solution 3: Do nothing

Simply keep with the current pattern, where some things are here, and others are upstream. This approach is probably workable for now, but in the long run for reliability and consistency and having a consistent runbook, etc., one of the other approaches is ideal.

Other factors and tradeoffs

Some of the tradeoff axes here include:

• Time to update: how fast do you respond to updates that go through upstream nixpkgs or your own extensions?
• Paying attention to upstream: how often do you spend tracking these extensions upstream and making sure they're QA'd for users? I think this is one of the most important, and ultimately I think whatever route you choose it's something you have to deal with. If you're going to pay attention to your upstreams, then 2 makes more sense. If you want to rely on the community to do that more, 1 makes more sense.
• Dev time: how often do you want people to do this? Should it be automated?

Austin's vote

I would vote weakly in favor of number 2 if I were taking this to production. Mostly, this just means that your own repository is the source of truth, and Nixpkgs is there mostly to provide tooling and PostgreSQL versions. Ideally everything would be defined here, even PostgreSQL builds, but where the responsibility for keeping up with your upstreams lies — that's the real question.