Call for Speakers: Join Us at Postgres Conference Seattle 2024!

We are excited to announce that the Postgres Conference Seattle 2024 is accepting speaker submissions! This is your chance to share your knowledge, insights, and experiences with the global PostgreSQL community in one of the world’s most innovative tech hubs. Whether you're a seasoned PostgreSQL expert or have unique insights on emerging trends, this is the perfect stage to amplify your voice and make an impact.

Why Speak at Postgres Conference: Seattle

As the largest PostgreSQL gathering in the U.S., Postgres Conference: Seattle 2024 brings together users, developers, DBAs, and thought leaders from diverse industries including FinTech, HealthTech, EdTech, and more! Here’s why you should consider submitting a proposal:

1. Expand Your Reach: Presenting at the conference will allow you to connect with hundreds of like-minded professionals, influencers, and companies shaping the future of data management.
2. Share Your Expertise: Whether you're a PostgreSQL guru or a curious learner with unique insights, your contribution can help others grow in their own Postgres journey.
3. Professional Recognition: Gain visibility and recognition within the Postgres community and broader tech industry. Being a speaker enhances your profile and can open doors for future collaborations, partnerships, or even job opportunities.
4. Contribute to the PostgreSQL Ecosystem: PostgreSQL continues to evolve rapidly. By sharing your experiences, you contribute to the collective growth and innovation of this incredible open-source database system.

Tracks for Every Interest

We’re looking for speakers across various areas of expertise. If you work in development, operations, or the essential aspects of PostgreSQL usage, we want to hear from you! Here’s a quick overview of our three main tracks:

Development (Dev) Track

Do you have cutting-edge insights on PostgreSQL development? This track is for talks focused on building, optimizing, and scaling applications using PostgreSQL. Some of the topics you could cover include:

• Query optimization and performance tuning
• Building and deploying PostgreSQL-based applications
• Best practices in database schema design
• Case studies of innovative solutions using PostgreSQL

Whether you're diving into PL/pgSQL, extending Postgres with custom functions, or exploring advanced indexing techniques, this is the perfect platform to share your expertise with fellow developers.

Operations (Ops) Track

If you’re working behind the scenes, ensuring that PostgreSQL environments are secure, scalable, and high-performing, the Ops track is for you. This track seeks submissions from database administrators, SREs, DevOps engineers, and anyone involved in the operational side of PostgreSQL, such as:

• Scaling PostgreSQL for high-traffic applications
• Backup and recovery strategies
• Monitoring and observability tools
• Managing multi-region or cloud-based Postgres instances

Share your experience on how to keep PostgreSQL running smoothly, even under the most demanding conditions.

Essentials Track

The Essentials track is perfect for those who want to speak about the core foundational aspects of PostgreSQL. It’s an ideal opportunity to present content geared toward people who are new to PostgreSQL or seeking to deepen their understanding of its key concepts. Suggested topics might include:

• Introduction to PostgreSQL for beginners
• SQL best practices and optimization
• Setting up a robust PostgreSQL environment
• Security fundamentals for database management

This track encourages first-time speakers and practitioners who want to help others navigate the essentials of working with PostgreSQL.

How to Submit Your Proposal

Submitting a proposal is easy! Simply prepare an abstract that describes your talk, its relevance to the conference tracks, and what attendees will take away from it. We encourage submissions from individuals of all backgrounds and levels of experience. Diversity of thought and experience enriches the conversation, and we welcome fresh perspectives.

Create a user account and submit your abstract, title, and description for review consideration.

Take this opportunity to shine as a thought leader in the Postgres world. Share your journey, inspire innovation, and connect with a vibrant community that’s as passionate about Postgres as you are. Submit your proposal today and join us in Seattle for an unforgettable experience!

Important Dates:

Submission Deadline: Monday, September 30th, midnight Pacific Time/ 3 am ET

Event Dates: November 6 - 7, 2024

Ready to Submit?

To submit your proposal and find more details, head to our submission page. Questions can be directed to organizers@postgresconf.org. We look forward to seeing you in Seattle!

We can’t wait to hear from you. Let’s shape the future of Postgres together!

Welcome to "Cultivating DEI" , a series in which Postgres community members share their insight and experience about creating a more diverse and inclusive Postgres environment where all are welcome.

Recently I've been thinking a lot about relationships between the PostgreSQL community and the Database research community. To put it bluntly – these two communities do not talk to each other!

There are many reasons why I am concerned about this situation. First, I consider myself belonging to both of these communities. Even if right now I am 90% in industry, I can't write off my academic past. Writing a scientific paper with the hope of being accepted to the real database conference is something which appeals to me.

Secondly, we want to have quality candidates for database positions. Anyone who has tried recently to fill these positions knows that this is not an easy task. If you are looking at recent college grads, there are almost no chances that you can find somebody who has PostgreSQL experience. Here is where we face the other side of the problem.

The problem is not simply that scientists do not speak at the PostgreSQL conferences, and that PostgreSQL developers do not speak at academic conferences. The larger issue is that for many Computer Sciences (CS) students, their academic research and practical experience do not intersect. They learn about some incredible algorithms, and as part of their coursework they may suggest some enhancements to existing algorithms. They then practice their SQL skills with MySQL, which from my observations lacks so many basic features, that it can hardly be taken seriously as a data platform.

If students practiced using PostgreSQL, they would have a full-scale enterprise ready object-relational database -- not a "light" version, but a robust platform, which supports a multitude of index and data types, constraints, procedural languages and much more.

I've heard from several professors that "MySQL is okay for "learning SQL." I want to ask -- what does "learning SQL" mean? Is it just learning how to write a syntactically correct SQL? One contributing factor to the problem is that MySQL comes on each laptop by default, integrated with basic tools that allow building websites. It is integrated with Wordpress. There is no reason for PostgreSQL not to have similar support, but it is not in place.

This is particularly frustrating when you recognize the amount of database research was completed using Postgres, for Postgres or with help of Postgres; R-Tree and GIST indexes, for example. Also, the SIGMOD Test of Time Award in 2018 went to the paper "Serializable isolation for snapshot databases," which was implemented in PostgreSQL.

I know the answer to the question "why do they not talk?" Researchers do not want to talk at the PostgreSQL conferences, because those are not scientific conferences, and participation in these conferences will not result in a publication. Postgres developers do not present at the CS conferences, because they do not want to write long papers. Even if they do submit something, their papers are often rejected as "not having any scientific value." I have experienced this on multiple occasions.

I came across another example of "why” when I attended the ACM/SIGMOD conference in Amsterdam. I attended a compelling presentation on the problem of cardinality estimation over multi-join queries, that introduced new optimization techniques. The presenter mentioned that he had used Postgres to build the prototype. I was too far back in the room to ask my question, so I reached out via the conference website.

I asked the presenter why he didn't submit a patch. He replied that their approach was hacky, and it needs more work to think about adding it to Postgres. I've asked whether he would be interested in working on it with some PostgreSQL community members. His reply? "Not in the next two years, I've just received a post-doc position at Microsoft, so I can't do it for the next two years."

So yes -- I know the answer as to why these two communities historically do not communicate. However, I do not like or accept it. Perhaps we can talk about and resolve this problem together?!

Contributor Bio:

Henrietta Dombrovskaya is a database researcher and developer with over 30 years of academic and industrial experience. She holds a Ph.D. in Computer Science from University of Saint Petersburg, Russia. She taught Database and Transaction theory at the University of Saint – Petersburg (Russia), as well as multiple database tuning classes for both beginners and advanced professionals.

Her professional experience includes consulting for a number of government projects in Chicago and New York, and providing Data services in the financial sector, manufacturing, and distribution. She is a co-author, with B. Novikov, of the book “System Tuning”, BHV, S.-Petersburg, Russia. Her researches in overcoming object-relational impedance mismatch were publish in the Proceedings of EDBT 2014 Athens and ICDE 2016 in Helsinki. At Braviant Holdings she is happy to have an opportunity to implement the results of her research in practice.

Henrietta Dombrovskaya is a co-organizer of the Chicago PostgreSQL User Group and a member of the Diversity, Equity, and Inclusion Work Group for the Postgres Conference Series. She was recently awarded the 2019 "Technologist of the Year" award by the Illinois Technology Association. This award is  "presented to the individual whose talent has championed true innovation, either through new applications of existing technology or the development of technology to achieve a truly unique product or service."

As part of the countdown to PostgresConf US 2018, learn more about the engaging content and our Diamond and Platinum sponsors for this year in our Sponsor Spotlight Series.

Brad Nicholson is a database engineer and the PostgreSQL team lead at Compose, an IBM Company, which is one of our Platinum Sponsors for PostgresConf US 2018. Compose runs a PostgreSQL as a service platform, and has long been a supporter of the Postgres community through contributions and support. Read what Brad has to say about Compose and Postgres:

Tell us about your commitment and contribution to the Postgres Community.

Postgres is a big part of our business, and one that is rapidly growing.  As such, our  commitment is pretty self-explanatory – we are committed to postgres and the PG Community. Basically, the better PG is/becomes, the better product we can build on top of it. Our biggest contribution to the community is probably Governor.  While we have since deprecated that project, Patroni is a fork of it, and uses the HA template we created with Governor. 


What particular challenges did you face when building multi platform deployments with Postgres?

Lack of management API was one of the biggest challenges.  This leads to less than desirable patterns like having to run Patroni and Postgres in the same container, effectively tying the lifecycle of the two together. There are also a number of places where log parsing is still required to ensure the validity of an operation (like ensuring PITR \ restores actually restored to the point you specified).  These sorts of patterns are challenging to handle and often lead to less than desirable architectural patterns at the platform level.

What growth pattern do you expect for yourself as well as Postgres as a whole?

I've been using Postgres since 2001. To watch its growth over the years has been impressive, especially over the past few years.

Postgres has long established itself as the number one Open Source RDBMS.  With the huge shift we have seen towards open source adoption in the past several years, I only see it's growth continuing to accelerate.

As an organizer of the Toronto Postgres User Group I'd personally like to get more involved in the community again.  I'm not a C developer, so advocacy and helping people out via the lists/slack/etc where I can.  Now that we've deprecated Governor, I'm also looking forward to contributing to the Patroni project more.

What features would you like to see in v11 and v12?

My number one ask is Failover Slots.  Without them, it makes it difficult to for us to give our customers access to Logical Replication and Logical Decoding.  We use streaming replication for HA, and abstract those details away from our users. A HA failover will break whatever systems are built on these constructs - we lose the replication slot that maintains the place in the decoding stream, most likely requiring a resync of the dependent systems.  That is not a great story for people building downstream systems.

The other thing I'd love to see is connection pooling in core.  This has been a huge Achilles heel in Postgres for ages. Pgbouncer and pgPool are nice products to help work around the limitations, but they are severely limited when it comes to multi-tenant systems.These systems frequently need to spread their connections out across multiple users and/or multiple databases within a given cluster. Because we can't share these connections via external pools, we end up with connection explosions. 

What is the number one barrier you see to contributing to the Postgres community?

 Not a very exciting answer, but time. There just aren't enough hours in the day to fit everything in.

What is the best thing about working with the Postgres community?

How helpful, open and responsive the people in the Community are.  When you have a question or problem, getting direct access to people via the mailing lists, Slack, etc is great.  Often you'll be talking with the folks that wrote the code in the first place.  People are always really helpful.

Tell us why you believe people should attend PostgresConf 2018 in April.

This conference is an amazing opportunity to learn about all sort of different areas from the experts.  Meeting folks face to face is always another huge benefit.

Visit the Compose team in the Exhibit Hall in the Newport Grand Ballroom on Wednesday, April 18, and Thursday, April 19.  IBM Senior Developer Advocate Raj Singh will present  "Do data science and machine learning with Postgres on the IBM Cloud" in his keynote on April 19 at 3 pm, which also takes place in the Newport Grand Ballroom.

Check out the full schedule for PostgresConf US 2018, and buy your tickets soon!