Threads
Loading user profile...
You can run pg18 if you self-host - you have to prepare your own postgres containers but if you are on kubernetes 1.35+ using cloudnative-pg, that is pretty easy now. There is no support for uuidv7 on the auth.users table though...
not yet @nimbit-software . Supabase make it very hard to keep up a self-hosted system by refusing to have any discipline in their individual projects (quality varies *very* widely) and a truly shameful documentation situation. Anyone who values their customers and customers' data would never rely on Supabase's SAAS offerings... because they obviously don't have any serious internal processes. So I only come and look at stuff every few months when I want to update something and decide to update everything.
@krishparmar22242 , do you have some walk-throughs or explicit docs proving `Many self-hosted users have already successfully moved to`? "S3-compatible" is not all-or-nothing. For example, `Garage` has a [list of what similar apps implement what APIs](https://garagehq.deuxfleurs.fr/documentation/reference-manual/s3-compatibility/) (though it's missing rustfs, which is a bit annoying). For example, `riakcs` and `openstack swift` are both apparently "S3-compatible" but they don't (according to that table) support [ListObjectsV2](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectsV2.html), and I'm pretty sure `supabase` uses that, so they wouldn't work, in spite of being "compatible". `minio` had quite good coverage of the API, though maybe not as good as `ceph` (I don't know either way).
The new kubernetes 1.35 (stable, 1.33+ feature-gated, as long as you have a compatible runtime) and cloudnative-pg 1.27+, along with postgres 18+, you can do dynamic loading of extensions via `imagevolume` mounts. Here is a dockerfile for creating the container to mount: [Dockerfile.txt](https://github.com/user-attachments/files/25858752/Dockerfile.txt) Which you can then make available and configure like the following: ``` spec: ... kind: Cluster spec: ... postgresql: ... extensions: - name: pgvector image: reference: ghcr.io/cloudnative-pg/pgvector:0.8.1-18-trixie - name: postgis image: reference: ghcr.io/cloudnative-pg/postgis-extension:3.6.1-18-trixie ld_library_path: - system - name: pgaudit image: reference: ghcr.io/cloudnative-pg/pgaudit:18.0-18-trixie - name: supabase image: reference: your.repo/utils/supabase-extensions:0.0.1-18-trixie ld_library_path: - system ... ``` I haven't tested it very extensively yet but for the moment it seems to be working well with pg18 and the versions of the extensions available in `pgdg` and `pigsty` (see the dockerfile for details) and was a drop-in upgrade from previously using upstream's 17.6 image. I ran exactly the same sql image referenced above to do the basic migrations. It is missing `pgroonga` as I'm not sure how to do that yet with the new extensions system (there are lib header and binaries to copy also) but it *looks* like everything else Just Works©. The rest of the above config stays identical!
Looking at `cnpg-supabase`, I can't for the life of me work out how the extensions are done... The `values.yaml` just has `imageName: ghcr.io/cloudnative-pg/postgresql:17.6-minimal-trixie`... And that's missing, well, basically all the extensions. So how does one get the extensions?
Public storage bucket too