PostgreSQL is an incredible general-purpose database, but it can't do everything. Every design decision is a tradeoff, and inevitably some of those tradeoffs get fundamentally baked into the way it's built. Take storage for instance - Postgres tables are row-oriented; great for row-by-row access, but when it comes to analytics, it can't compete with a dedicated OLAP database that uses column-oriented storage. Or can it? Joining me this week is Philippe Noël of ParadeDB, who's going to take us on a tour of Postgres' extension mechanism, from creating custom functions and indexes to Rust code that changes the way Postgres stores data on disk. In his journey to bring Elasticsearch's strengths to Postgres, he's gone all the way down to raw datafiles and back through the optimiser to teach a venerable old dog some new data-access tricks.  – ParadeDB: https://paradedb.com ParadeDB on Twitter: https://twitter.com/paradedb ParadeDB on Github: https://github.com/paradedb/paradedb pgrx (Postgres with Rust): https://github.com/pgcentralfoundation/pgrx Tantivy (Rust FTS library): https://github.com/quickwit-oss/tantivy PgMQ (Queues in Postgres): https://tembo.io/blog/introducing-pgmq Apache Datafusion: https://datafusion.apache.org/ Lucene: https://lucene.apache.org/ Kris on Mastodon: http://mastodon.social/@krisajenkins Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/ Kris on Twitter: https://twitter.com/krisajenkins