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
