Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sMt6t-005JLd-82 for pgsql-general@arkaria.postgresql.org; Thu, 27 Jun 2024 17:40:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sMt6r-00CKyj-Jy for pgsql-general@arkaria.postgresql.org; Thu, 27 Jun 2024 17:40:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sMt6r-00CKya-91 for pgsql-general@lists.postgresql.org; Thu, 27 Jun 2024 17:40:37 +0000 Received: from fhigh6-smtp.messagingengine.com ([103.168.172.157]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sMt6p-003rCc-3j for pgsql-general@lists.postgresql.org; Thu, 27 Jun 2024 17:40:37 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 2ED04114016A; Thu, 27 Jun 2024 13:40:33 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 27 Jun 2024 13:40:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1719510033; x=1719596433; bh=GUmUHsatBAuV8snfHWSlwLK/vW6bcNK9RYlUP0Z3wL8=; b= utNfIy5Fs0YPQHJ+ptrQbFhld0P5bbJa3rmpweN/OcF1qD6mxK913jzwD+hbnLFN ckONPTkpsKl0QI2uAfXa2Qu8/9eRAs8xAX3AXFg3KrdVPtSCy7bZ4vnKATG8A44Y uNy3qRxFByTtX/Yg24es4L61dYqQZTPMdPswYScv2lMEmlk6HkQQtw11k3ZGnQ8N nNF+V4yzEsF7GFiU7Rgrarl4L1v67r51gn67hK51mXLw4fFMYOvVrb4FXKnNs5oS VvWXLP4eewNUS/xLfxZfsIFmS3+0yoRuORPPa8C3BEsbVL1Tpn4Tanr8G4Y0OwKQ Q2RxSehAZgTkJte3ftxFyQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1719510033; x= 1719596433; bh=GUmUHsatBAuV8snfHWSlwLK/vW6bcNK9RYlUP0Z3wL8=; b=t yzK5rGo289r42Jtd7SPE1FDO++o+SfgN3AoYXi+qSUQuxw44w8xgsBscT5oJ8/WZ S+1ugalbN9eNv22HOK1mgO1PURyHel83i5GbACXSVzg3C2WM/RGGOg7G7bTcJGQV YD3jnjPFb6bBg1CMNF3J5vxN29V+fBHOZ0R23y965Pfv4etAXXSdurFd46P0bNZf L+Qgwjga+DQqlgzc+vu5vBoI6cSiDCSWHPKy5OR1MUZQXFPmcyL4+9eURl4HpEHq 1pUaamugYkouZGtwKt2qlMM9a15uxWVqUC8SCaSc0jo3ur73Si9eB/mLFLYEHgE0 nvEgcOS8UQkFFpMHQiZUA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrtdeggdduudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtje ertddtvdejnecuhfhrohhmpeetughrihgrnhcumfhlrghvvghruceorggurhhirghnrdhk lhgrvhgvrhesrghklhgrvhgvrhdrtghomheqnecuggftrfgrthhtvghrnhepiedvhfeihe ehgeeuieeljeeitedtjeehudegfeelkedvleekhedtgfeiffefkedunecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprggurhhirghnrdhklhgrvh gvrhesrghklhgrvhgvrhdrtghomh X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 27 Jun 2024 13:40:32 -0400 (EDT) Message-ID: <3ee1729e-58b1-4eb8-bc9a-1b5a580d18c9@aklaver.com> Date: Thu, 27 Jun 2024 10:40:31 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Alignment check To: Marthin Laubscher , pgsql-general@lists.postgresql.org References: <7644D22D-BFB3-4471-B077-30797AA838FC@lobeshare.co.za> Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 6/27/24 10:26, Marthin Laubscher wrote: > On 2024/06/27, 19:04, "Adrian Klaver" > wrote: >> And substituted a single platform dependence. > > Even bare metal can lock you in without some abstraction layer between your code and the hardware. It's true that Kubernetes is a "single platform" but it provides the same facilities in all of its guises from bare metal implementations to what you can rent on demand from public clouds. I've made peace with that being about as cloud-agnostic as I can realistically achieve. > >> Which now leads you to above. > > To me that's a good thing. I've got no time for puristic idealism. It's a pragmatic choice which always involve compromises. "Compromise knowingly", an old manager of mine used to say. > > Yugabyte, if I did go with it, would have been a tough choice because it would lock me into them as database vendor which would only make sense if it unlocked a massive performance upside. For all intents and purposes I'm already locked into PostgreSQL as my application's database because it's reliant on a custom extension like no other database would let me do. But single database isn't single vendor, as long as it's open source. If YugabyteDB did support my extension (I tried but they won't consider for their DBaaS/Managed/Yugabyte Anywhere/Yugabyte Aeon commercial product built on top of an old version of PostgreSQL) it would have meant that in a pinch I could rent additional capacity from their commercial offering while I expand my own points of presence. That kite's not going to fly though, so I'm back to dealing with all of the data distribution logic in my application layer itself. > > So when you're done trolling me and my choices, feel free to comment on the actual question. > Not trolling just pointing out what you described above. Sometimes simple is not and you end up going through all sorts of contortions to stick to the plan. Just an observation take it or leave as you like. -- Adrian Klaver adrian.klaver@aklaver.com