Interview with Peter Boncz
- Efficient Graph Analysis with SQL/PGQ
- Wednesday, 09:50
- Berlin 1
- Could you briefly introduce yourself?
My name is Peter Boncz and I am a well-known database architect, creating systems like MonetDB, VectorWise. I am also involved in DuckDB and Databricks Spark.
My biggest claims to fame may be column stores, vectorized query execution and fast compression methods for column stores. These techniques are now common in analytical database systems and data formats like Parquet.
Further I am also interested in graph data management, but I think most graph data is underexploited as it lurks in common relational tables. This is also why I am excited that new SQL:2023 standard will add support for querying such graphs. This comes after joint work of ISO with a graph standardization organization I founded called LDBC (ldbcouncil.org).
- How do you engage with the PostgreSQL Community?
Well, we have Ilaria Battiston, who is active in the community in our database research group at CWI now. But LDBC has also interacted with the PostgreSQL community through people from 2ndQuadrant. I would be super excited if the new graph functionality would also get implemented in PostgreSQL.
- Have you enjoyed previous PostgreSQL Europe conferences, either as an attendee or as a speaker? (PGConf.EU, FOSDEM PGDay, Nordic PGDay, pgDay Paris, PGConf.DE)
No, it is a first time! I have of course visited a lot of academic database conferences like SIGMOD and VLDB, and also some Spark events, but I am excited to get to know the PostgreSQL crowd.
- What will your talk be about, exactly? Why this topic?
I will be talking about the SQL/PGQ (that stands for Property Graph Query) part of the new SQL:2023 standard. Property Graphs have been made popular by neo4j, but now we will be able use these concepts in relational data. I will give some background on various graph query languages and explain from where SQL/PGQ evolved.
A second topic is about making fast analytical database systems. CWI now has created a new analytical engine called DuckDB. It uses compress columnar storage, vectorized query execution and a number of other state-of-the-art techniques. These technique I will related to the current architecture of PostgreSQL.
- What is the audience for your talk?
People interested in learning how database systems work. And people interested in querying graphs and the new SQL standard.
- What existing knowledge should the attendee have?
My talk will require some general computer science knowledge and knowledge about relational database systems.
- What is the one feature in PostgreSQL 15 which you like most?
I am hoping for SQL/PGQ in PostgreSQL 16
- Which other talk at this year’s conference would you like to see?
Have to still look at the program, but I am sure there are plenty of things of interest.
- Which measure, action, feature or activity would—in your eyes—help to accelerate the adoption of PostgreSQL?
I think PostgreSQL is already strongly adopted. The easier it is to install and manage the system, the better.
- How Could DuckDB and PostgreSQL work in symbiosis?
DuckDB and PostgreSQL are complementary systems as DuckDB has very high analytical query performance (handles large data volumes, uses parallelism, handles big joins, sorts and aggregations), and PostgreSQL is very good at transactions.
Recently, DuckDB introduced a native PostgreSQL reader that allows it to perform analytical queries efficiently on live and changing PostgreSQL databases. Both systems share the same SQL parser and are quite compatible and such a combined setup could be useful for people with mixed workloads (HTAP).