<story><title>Thoughts on PostgreSQL in 2024</title><url>https://jkatz05.com/post/postgres/postgresql-2024/</url></story><parent_chain></parent_chain><comment><author>philippemnoel</author><text>This is a great post. As an extension developer myself (pg_bm25), seeing more native support for search-related functionalities that extensions can harness would be really great.&lt;p&gt;I&amp;#x27;m surprised nothing was mentioned around pgBouncer&amp;#x2F;connection pooling. Having more native support for general connection pooling has been a requested feature in Postgres for a while, and many popular DBMS have it built-in. Just how some of what Patroni offer should be better bundled in (as the author argues), I think the same could&amp;#x2F;should be true for pgBouncer</text></comment>
<story><title>Thoughts on PostgreSQL in 2024</title><url>https://jkatz05.com/post/postgres/postgresql-2024/</url></story><parent_chain></parent_chain><comment><author>hinkley</author><text>&amp;gt; Logical replication allows the real-time streaming of changes from a database into any system that can understand the PostgreSQL logical replication protocol.&lt;p&gt;My Christmas wish for 2024-2025 is that we have an industry standard format for replication. A simple transform (hopefully) of either WAL or logical replication, that we can feed into backup software, search, analytics, whatever.&lt;p&gt;There&amp;#x27;s something out there that fulfills the duties of Kafka and half a dozen other tools (at least two of which don&amp;#x27;t exist yet due to significant barriers to entry) with about a quarter of the code. We just need to carve it out of the block of marble.</text></comment>