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