Simran

<div class="ql-editor read-mode"><p><span style="background-color: transparent; color: rgb(21, 40, 61);"><img src="/files/DzWdWWA.png" height="52" width="206"></span></p><p><strong style="background-color: transparent; color: rgb(230, 110, 50);">DATABASE ARCHITECTURE</strong></p><p><strong style="background-color: transparent; color: rgb(22, 78, 133);">The Day CREATE EXTENSION Became a Platform Decision</strong></p><p><span style="background-color: transparent; color: rgb(92, 107, 120);">Why useful PostgreSQL capabilities need a catalogue, compatibility evidence and an owner.</span></p><p><em style="background-color: transparent; color: rgb(21, 40, 61);">A developer asked for one extension to solve one problem. The SQL took seconds. The review uncovered an operating-system package, a shared library, a preload change, background workers and an upgrade dependency that would live for years.</em></p><p><strong style="background-color: transparent; color: rgb(230, 110, 50);">Start with one workload | Scale into a complete platform | Open Source Freedom | Enterprise-Grade Operations.</strong></p><p><span style="background-color: transparent; color: rgb(21, 40, 61);">Published | January 2026</span></p><h1><strong style="background-color: transparent; color: rgb(22, 78, 133);">The question behind the obvious answer</strong></h1><p><span style="background-color: transparent; color: rgb(21, 40, 61);">A developer asked for one extension to solve one problem. The SQL took seconds. The review uncovered an operating-system package, a shared library, a preload change, background workers and an upgrade dependency that would live for years.</span></p><p><span style="background-color: transparent; color: rgb(21, 40, 61);">Extensions are part of PostgreSQL’s strength, but unmanaged extensions turn database freedom into hidden platform coupling.</span></p><table class="table table-bordered"><tbody><tr><td data-row="1"><strong style="background-color: transparent; color: rgb(21, 40, 61);"><em>An Extension Is Code Inside The Database Trust Boundary.</em></strong></td></tr></tbody></table><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">The turning point</strong></h2><p><span style="background-color: transparent; color: rgb(21, 40, 61);">The platform introduced an approved catalogue that connected business use, PostgreSQL version, package provenance, runtime requirements, licensing and rollback constraints.</span></p><p><span style="background-color: transparent; color: rgb(21, 40, 61);">The team used OSS Manager to make approved PostgreSQL extension lifecycle reviewable and repeatable. The engine still owned its native behaviour; the control plane made intent, prerequisites, execution and evidence visible to the people responsible for the service.</span></p><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">What had to become explicit</strong></h2><ul><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">The service boundary: An approved extension catalog maps PostgreSQL and operating-system versions to signed packages, preload requirements, database enablement, rollback constraints, and test evidence.</span></li><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">The operational controls: allow-list, package signature and SBOM, binary compatibility, preload change review, dependency graph, database scope, backup, rollback, and license review.</span></li><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">The capacity conversation: extension workload, memory and background workers, index growth, maintenance cost, query patterns, package footprint, and upgrade duration.</span></li><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">The human boundary: who may observe, who may approve, who may execute, and who decides whether the application is ready.<br></span></li></ul><h1><strong style="background-color: transparent; color: rgb(22, 78, 133);">The architecture that changed the conversation</strong></h1><p><span style="background-color: transparent; color: rgb(21, 40, 61);">The diagram is deliberately centred on the decision the team had to make. It is not a product inventory. It shows where authority sits, what crosses the boundary, and where a failed assumption must stop the workflow.</span></p><p style="text-align: center;"><span style="background-color: transparent; color: rgb(21, 40, 61);"><img src="/files/xqqH8uY.png" height="454" width="888"></span><strong style="background-color: transparent; color: rgb(22, 78, 133);"><br></strong></p><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">The practical design choices</strong></h2><table class="table table-bordered"><tbody><tr><td data-row="1"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Gate</strong></td><td data-row="1"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Question</strong></td><td data-row="1"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Evidence</strong></td></tr><tr><td data-row="2"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Compatibility</strong></td><td data-row="2"><span style="background-color: transparent; color: rgb(21, 40, 61);">Will it survive the next major version?</span></td><td data-row="2"><span style="background-color: transparent; color: rgb(21, 40, 61);">Version matrix</span></td></tr><tr><td data-row="3"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Runtime</strong></td><td data-row="3"><span style="background-color: transparent; color: rgb(21, 40, 61);">Does it need preload or workers?</span></td><td data-row="3"><span style="background-color: transparent; color: rgb(21, 40, 61);">Restart and resource plan</span></td></tr><tr><td data-row="4"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Recovery</strong></td><td data-row="4"><span style="background-color: transparent; color: rgb(21, 40, 61);">Can backups restore the objects?</span></td><td data-row="4"><span style="background-color: transparent; color: rgb(21, 40, 61);">Restore test</span></td></tr><tr><td data-row="5"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Security</strong></td><td data-row="5"><span style="background-color: transparent; color: rgb(21, 40, 61);">What code enters the trust boundary?</span></td><td data-row="5"><span style="background-color: transparent; color: rgb(21, 40, 61);">Package provenance and privilege review</span></td></tr><tr><td data-row="6"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Licensing</strong></td><td data-row="6"><span style="background-color: transparent; color: rgb(21, 40, 61);">Can it be redistributed and supported?</span></td><td data-row="6"><span style="background-color: transparent; color: rgb(21, 40, 61);">Approved licence and ownership record</span></td></tr></tbody></table><p><span style="background-color: transparent; color: rgb(21, 40, 61);">These choices are intentionally small enough to review and test. They keep the architecture tied to operating behaviour instead of allowing a visually impressive diagram to hide unclear ownership.</span></p><h1><strong style="background-color: transparent; color: rgb(22, 78, 133);">What OSS Manager changed - and what it did not</strong></h1><p><span style="background-color: transparent; color: rgb(21, 40, 61);">OSS Manager brought discovery, planning, guarded execution and normalised status into one path for PostgreSQL. It did not replace the engine's correctness model or the application's responsibility for data semantics.</span></p><ul><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">Before change, validate versions, hosts, identities, artifacts, topology and the recovery boundary without mutating the service.</span></li><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">During change, persist progress, expose stop conditions and prevent a partial result from being mistaken for success.</span></li><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">After change, observe extension version; load success; background worker health; error log; query latency; resource use; package drift; unsupported dependency and run representative application journeys, not only process checks.</span></li><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">For recovery, protect the last known-good authority and require an explicit decision before promotion, rollback or destructive cleanup.</span></li></ul><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">The failure modes worth rehearsing</strong></h2><p><span style="background-color: transparent; color: rgb(21, 40, 61);">The test plan should make room for missing shared library, incompatible ABI, preload error, dependency conflict, extension update failure, catalog drift, unsupported downgrade, and license exception. The purpose is not to produce a longer checklist. It is to learn whether operators can recognise the failure and choose the safe next action while the evidence is incomplete.</span></p><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">A human operating model</strong></h2><p><span style="background-color: transparent; color: rgb(21, 40, 61);">L1 operators need a plain-language answer to what is healthy, what is delayed and whether a change is in progress. Platform engineers need topology and evidence. Application owners need to know what users will experience. A useful platform connects those views without giving every person the same privileges.</span></p><table class="table table-bordered"><tbody><tr><td data-row="1"><strong style="background-color: transparent; color: rgb(21, 40, 61);"><em>The catalogue did not reduce innovation. It shortened the path from a good idea to a supportable production capability.</em></strong></td></tr></tbody></table><h1><strong style="background-color: transparent; color: rgb(22, 78, 133);">Where this pattern earns its place</strong></h1><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">Media and OTT</strong></h2><p><span style="background-color: transparent; color: rgb(21, 40, 61);">This pattern is relevant where teams need regional continuity, burst traffic, low-latency serving and predictable recovery. The architecture must still be adjusted for local data classification, recovery objectives, workload shape and application behaviour.</span></p><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">Retail</strong></h2><p><span style="background-color: transparent; color: rgb(21, 40, 61);">This pattern is relevant where teams need campaign peaks, catalogue freshness, transaction continuity and rapid rollback. The architecture must still be adjusted for local data classification, recovery objectives, workload shape and application behaviour.</span></p><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">Telecom</strong></h2><p><span style="background-color: transparent; color: rgb(21, 40, 61);">This pattern is relevant where teams need high event volume, distributed operations, identity boundaries and service assurance. The architecture must still be adjusted for local data classification, recovery objectives, workload shape and application behaviour.</span></p><h1><strong style="background-color: transparent; color: rgb(22, 78, 133);">The lesson we would carry into the next project</strong></h1><p><span style="background-color: transparent; color: rgb(21, 40, 61);">The catalogue did not reduce innovation. It shortened the path from a good idea to a supportable production capability.</span></p><p><span style="background-color: transparent; color: rgb(21, 40, 61);">The strongest open-source platforms are not the ones with the most automation. They are the ones where automation makes ownership, risk and recovery easier for people to understand.</span></p><table class="table table-bordered"><tbody><tr><td data-row="1"><strong style="background-color: transparent; color: rgb(21, 40, 61);"><em>Start with one workload. Prove the operating model. Then scale it into a complete platform.</em></strong></td></tr></tbody></table><p><br></p></div>

Explore PostgreSQL extension security, compatibility, package provenance and lifecycle governance with clear ownership and reliable recovery

PostgreSQL Extension Management | OSS Manager

writing-the-day-create-extension-became-a-platform-decision

Writing  The Day CREATE EXTENSION Became a Platform Decision

<div class="ql-editor read-mode"><p><span style="background-color: transparent; color: rgb(21, 40, 61);"><img src="/files/DzWdWWA.png" height="52" width="206"></span></p><p><strong style="background-color: transparent; color: rgb(230, 110, 50);">DATABASE MODERNISATION</strong></p><p><strong style="background-color: transparent; color: rgb(22, 78, 133);">How a PostgreSQL Estate Became Manageable Without Starting Over</strong></p><p><span style="background-color: transparent; color: rgb(92, 107, 120);">A staged adoption story for teams with valuable databases, uneven automation and no appetite for a risky rebuild.</span></p><p><em style="background-color: transparent; color: rgb(21, 40, 61);">The estate had grown the way successful estates often do: one important database at a time. Each instance worked, each DBA knew its history, and almost none of that knowledge was encoded in a repeatable operating path.</em></p><p><strong style="background-color: transparent; color: rgb(230, 110, 50);">Start with one workload | Scale into a complete platform | Open Source Freedom | Enterprise-Grade Operations.</strong></p><p><span style="background-color: transparent; color: rgb(21, 40, 61);">Published | June 2026</span></p><p><br></p><h1><strong style="background-color: transparent; color: rgb(22, 78, 133);">A platform already in motion</strong></h1><p><span style="background-color: transparent; color: rgb(21, 40, 61);">The estate had grown the way successful estates often do: one important database at a time. Each instance worked, each DBA knew its history, and almost none of that knowledge was encoded in a repeatable operating path.</span></p><p><span style="background-color: transparent; color: rgb(21, 40, 61);">A clean-room rebuild would have created more risk than it removed. The organisation needed to discover what existed, transfer management deliberately, and preserve database authority throughout the transition.</span></p><table class="table table-bordered"><tbody><tr><td data-row="1"><strong style="background-color: transparent; color: rgb(21, 40, 61);"><em>The Database Did Not Need Replacing. The Operating Model Did.</em></strong></td></tr></tbody></table><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">The turning point</strong></h2><p><span style="background-color: transparent; color: rgb(21, 40, 61);">The journey was split into three visible stages: discover without mutation, adopt configuration and service ownership, then modernise backup, monitoring and lifecycle controls behind explicit gates.</span></p><p><span style="background-color: transparent; color: rgb(21, 40, 61);">The team used OSS Manager to make policy-driven PostgreSQL deployment and operations reviewable and repeatable. The engine still owned its native behaviour; the control plane made intent, prerequisites, execution and evidence visible to the people responsible for the service.</span></p><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">What had to become explicit</strong></h2><ul><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">The service boundary: OSS Manager coordinates a primary and replicas, connection endpoint, backup and WAL archive, monitoring, security, and controlled maintenance while PostgreSQL remains authoritative for transaction semantics.</span></li><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">The operational controls: major-version compatibility, replication and backup proof, role separation, extension inventory, configuration diff, service ownership, and application acceptance.</span></li><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">The capacity conversation: database and index size, working set, transaction rate, connection concurrency, WAL rate, replica count, backup window, retention, and growth.</span></li><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">The human boundary: who may observe, who may approve, who may execute, and who decides whether the application is ready.<br></span></li></ul><h1><strong style="background-color: transparent; color: rgb(22, 78, 133);">The architecture that changed the conversation</strong></h1><p><span style="background-color: transparent; color: rgb(21, 40, 61);">The diagram is deliberately centred on the decision the team had to make. It is not a product inventory. It shows where authority sits, what crosses the boundary, and where a failed assumption must stop the workflow.</span></p><p style="text-align: center;"><span style="background-color: transparent; color: rgb(21, 40, 61);"><img src="/files/3HavDM3.png" height="592" width="888"></span><strong style="background-color: transparent; color: rgb(22, 78, 133);"><br></strong></p><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">The practical design choices</strong></h2><table class="table table-bordered"><tbody><tr><td data-row="1"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Stage</strong></td><td data-row="1"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Question</strong></td><td data-row="1"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Exit condition</strong></td></tr><tr><td data-row="2"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Discover</strong></td><td data-row="2"><span style="background-color: transparent; color: rgb(21, 40, 61);">What is really running?</span></td><td data-row="2"><span style="background-color: transparent; color: rgb(21, 40, 61);">Inventory and risks reviewed</span></td></tr><tr><td data-row="3"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Adopt</strong></td><td data-row="3"><span style="background-color: transparent; color: rgb(21, 40, 61);">What can be standardised safely?</span></td><td data-row="3"><span style="background-color: transparent; color: rgb(21, 40, 61);">Config and ownership mapped</span></td></tr><tr><td data-row="4"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Operate</strong></td><td data-row="4"><span style="background-color: transparent; color: rgb(21, 40, 61);">Can another team recover it?</span></td><td data-row="4"><span style="background-color: transparent; color: rgb(21, 40, 61);">Restore and runbook accepted</span></td></tr><tr><td data-row="5"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Protect</strong></td><td data-row="5"><span style="background-color: transparent; color: rgb(21, 40, 61);">Is recovery independent of one DBA?</span></td><td data-row="5"><span style="background-color: transparent; color: rgb(21, 40, 61);">Backup, WAL archive and PITR proof</span></td></tr><tr><td data-row="6"><strong style="background-color: transparent; color: rgb(21, 40, 61);">Modernise</strong></td><td data-row="6"><span style="background-color: transparent; color: rgb(21, 40, 61);">Which capability changes are justified?</span></td><td data-row="6"><span style="background-color: transparent; color: rgb(21, 40, 61);">Approved HA, extension and replication plan</span></td></tr></tbody></table><p><span style="background-color: transparent; color: rgb(21, 40, 61);">These choices are intentionally small enough to review and test. They keep the architecture tied to operating behaviour instead of allowing a visually impressive diagram to hide unclear ownership.</span></p><h1><strong style="background-color: transparent; color: rgb(22, 78, 133);">What OSS Manager changed - and what it did not</strong></h1><p><span style="background-color: transparent; color: rgb(21, 40, 61);">OSS Manager brought discovery, planning, guarded execution and normalised status into one path for PostgreSQL. It did not replace the engine's correctness model or the application's responsibility for data semantics.</span></p><ul><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">Before change, validate versions, hosts, identities, artifacts, topology and the recovery boundary without mutating the service.</span></li><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">During change, persist progress, expose stop conditions and prevent a partial result from being mistaken for success.</span></li><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">After change, observe availability; replication lag; WAL growth; connection saturation; locks; slow queries; vacuum health; bloat; backup age; recovery readiness and run representative application journeys, not only process checks.</span></li><li data-list="bullet"><span class="ql-ui" contenteditable="false"></span><span style="background-color: transparent; color: rgb(21, 40, 61);">For recovery, protect the last known-good authority and require an explicit decision before promotion, rollback or destructive cleanup.</span></li></ul><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">The failure modes worth rehearsing</strong></h2><p><span style="background-color: transparent; color: rgb(21, 40, 61);">The test plan should make room for replica divergence, WAL archive gap, connection exhaustion, long transaction, blocked vacuum, missing extension library, backup failure, and accidental dual-primary risk. The purpose is not to produce a longer checklist. It is to learn whether operators can recognise the failure and choose the safe next action while the evidence is incomplete.</span></p><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">A human operating model</strong></h2><p><span style="background-color: transparent; color: rgb(21, 40, 61);">L1 operators need a plain-language answer to what is healthy, what is delayed and whether a change is in progress. Platform engineers need topology and evidence. Application owners need to know what users will experience. A useful platform connects those views without giving every person the same privileges.</span></p><table class="table table-bordered"><tbody><tr><td data-row="1"><strong style="background-color: transparent; color: rgb(21, 40, 61);"><em>Modernisation stopped meaning 'replace everything'. It became a controlled transfer from personal knowledge to a shared, testable platform practice.</em></strong></td></tr></tbody></table><h1><strong style="background-color: transparent; color: rgb(22, 78, 133);">Where this pattern earns its place</strong></h1><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">Retail</strong></h2><p><span style="background-color: transparent; color: rgb(21, 40, 61);">This pattern is relevant where teams need campaign peaks, catalogue freshness, transaction continuity and rapid rollback. The architecture must still be adjusted for local data classification, recovery objectives, workload shape and application behaviour.</span></p><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">Telecom</strong></h2><p><span style="background-color: transparent; color: rgb(21, 40, 61);">This pattern is relevant where teams need high event volume, distributed operations, identity boundaries and service assurance. The architecture must still be adjusted for local data classification, recovery objectives, workload shape and application behaviour.</span></p><h2><strong style="background-color: transparent; color: rgb(22, 78, 133);">Gaming</strong></h2><p><span style="background-color: transparent; color: rgb(21, 40, 61);">This pattern is relevant where teams need latency-sensitive sessions, leaderboards, event streams and regional player experience. The architecture must still be adjusted for local data classification, recovery objectives, workload shape and application behaviour.</span></p><h1><strong style="background-color: transparent; color: rgb(22, 78, 133);">The lesson we would carry into the next project</strong></h1><p><span style="background-color: transparent; color: rgb(21, 40, 61);">Modernisation stopped meaning 'replace everything'. It became a controlled transfer from personal knowledge to a shared, testable platform practice.</span></p><p><span style="background-color: transparent; color: rgb(21, 40, 61);">The strongest open-source platforms are not the ones with the most automation. They are the ones where automation makes ownership, risk and recovery easier for people to understand.</span></p><table class="table table-bordered"><tbody><tr><td data-row="1"><strong style="background-color: transparent; color: rgb(21, 40, 61);"><em>Start with one workload. Prove the operating model. Then scale it into a complete platform.</em></strong></td></tr></tbody></table><p><br></p></div>

Modernise PostgreSQL without a risky rebuild. Discover a staged approach to database adoption, backup, monitoring and recovery.