<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Image-Catalog on Unleashing the Power of Postgres in Kubernetes</title><link>https://www.gabrielebartolini.it/tags/image-catalog/</link><description>Recent content in Image-Catalog on Unleashing the Power of Postgres in Kubernetes</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 06 Aug 2026 22:08:58 +1000</lastBuildDate><atom:link href="https://www.gabrielebartolini.it/tags/image-catalog/index.xml" rel="self" type="application/rss+xml"/><item><title>CNPG Recipe 26 - Extension image catalogs</title><link>https://www.gabrielebartolini.it/articles/2026/08/cnpg-recipe-26-extension-image-catalogs/</link><pubDate>Thu, 06 Aug 2026 22:08:58 +1000</pubDate><guid>https://www.gabrielebartolini.it/articles/2026/08/cnpg-recipe-26-extension-image-catalogs/</guid><description>&lt;p&gt;&lt;em&gt;CloudNativePG lets the &lt;code&gt;ClusterImageCatalog&lt;/code&gt; carry extension images
alongside the operand, a capability every currently supported release
already has, so a &lt;code&gt;Cluster&lt;/code&gt; manifest only needs to name an extension and
nothing else. This recipe deploys the community&amp;rsquo;s
extension catalog and shows the operator resolving pgvector&amp;rsquo;s image,
paths and dependencies from a single, versioned source of truth per
PostgreSQL major version. More importantly, it is the piece of
infrastructure that turns extension distribution into a real ecosystem:
once an extension lands in the catalog, every Cluster that references it
inherits it for free, with no manifest ever needing to change again.&lt;/em&gt;&lt;/p&gt;</description></item></channel></rss>