Hacker Newsnew | past | comments | ask | show | jobs | submit | sjmiller609's commentslogin

At Tembo, we built Trunk (pgt.dev), which is a free and open source Postgres extension registry with over 200 extensions, published under the postgres license. We aim to improve the developer experience within the Postgres extensions ecosystem with a free, open source, and open-governance approach, which is why we hired David Wheeler, creator of the original extensions network PGXN. He made a blog about what he thinks the ideal extensions registry looks like, and we are looking for contributors or companies who want to collaborate to make it happen with Tembo. Our incentive at Tembo is to make extensions more popular and easier to work with in the PG community generally, so that people may then be interested in Tembo Cloud and other Tembo products, where we make working with extensions a first class product experience.


Is this hugged to death right now?


Looks like it is


I wish there was some way to compress JSON data across multiple rows, I often have very similar blobs in each row. Or some other way to reduce amount of storage for a lot of similar blobs across many rows, for example 10kB JSON where only one or two keys are different.


Found this a helpful explanation


As a devops / platform guy, I would have typically made something like this by gluing a bunch of cloud / data tools together. e.g. like an ETL tool, orchestrator tool, maybe some process that dumps a DB, run a custom script, etc.

After working with extensions more, I really feel like some of these postgres-internal options should be assessed instead of always defaulting to the cloud tools or custom scripting stuff. In a lot of cases, it's way easier and cheaper to just use an extension, and there's really no big risk since it's just using the extension for an ETL job basically.


I wrote a guide and simple experimental setup for this extension: https://tembo.io/blog/table-version-history


I like how S3 object versioning and expiry works. I wanted something like that for Postgres tables, so I tried out a couple of extensions and wrote about what I found.


Before working for a Postgres company, I had never used extensions.

Now, I'm part of a team working to fully automate turning on any extension. I didn't find great resources to explain the process of turning on an extension, and why it varies between different extensions.

I want to share my mental model for the different types of extensions, how to know what type of extension you're working with, and how to get it turned on.


That is awesome! Did you consider using the temporal_tables extension? I think it's basically like version history for tables. I haven't used this before personally though. https://pgt.dev/extensions/temporal_tables


I didn't - I hadn't seen that extension before, it looks like it could be really useful in the future!

For my purposes here the feature I care most about is backups - having my content backed up to a GitHub repo feels extremely robust, since I know GitHub mirror content to (I believe) three continents.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: