Blog

The future of community in light of Babelfish

(adapted from PGConf NYC 2021 Keynote)

 

Ryan Booz

Director, Developer Advocacy

Timescale

Twitter: @ryanbooz

Email: ryan@timescale.com



On December 1, 2020, at its annual re:Invent conference, Amazon AWS announced Babelfish -  an open source PostgreSQL translation layer that allows SQL Server applications to work natively, and transparently, with PostgreSQL. To be honest, as someone that's spent a significant part of my career using both SQL Server and PostgreSQL, this wasn't actually a very “exciting” development.

 

I'm not sure that most people in either community really gave it that much notice a year ago. In fact, my first thought was that Babelfish is just an oversized Object-Relational Mapping (ORM) framework that wasn't tied to any specific development language. While these tools have proven to be hugely useful to many developers, nearly every DBA has first-hand war stories that demonstrate the challenge that automated query generation can impose on a complex system. Frankly, the thought terrifies me a bit.

 

Until recently, however, all we knew about Babelfish was based on Amazon published content. But in October 2021, Babelfish was finally released for public access and preview at https://babelfishpg.org/

 

Not long after the release was announced, I had the opportunity to participate in a video call with some members of the European PostgreSQL community for a first look at Babelfish in real life. It was interesting, and kind of exciting to see what worked and what didn't. However, I didn't leave that call any less concerned about the struggles my SQL Server friends will have as their management teams mandate switching to PostgreSQL using Babelfish. It also got me thinking - why SQL Server? 

 

I decided to look at DB-engines.com to see if the engagement metrics that they track would shed any light on it. Although the website doesn't disclose the specific method for determining database engine rank, we know that social engagement and search engine trends play a role in the rankings. 

 

When I zoomed in on the four "major" relational database engines, utilizing the last 9 years of data, two things jumped out at me.

 

  1. Only PostgreSQL has seen consistent increases in popularity and engagement over the 9 years of tracking
  2. While the three other engines have had some steady decline over the same period, SQL Server seems to have the biggest drop off compared to Oracle and MySQL

While I can posit many reasons why Amazon AWS chose to go directly after SQL Server for this transparent compatibility tool, the reasons to use PostgreSQL as the solution to the problem is obvious to the PostgreSQL community. PostgreSQL:

  • is the fastest growing, relational database engine on the planet
  • has a proven foundation
  • is easy to enhance through extensibility

 

Regardless of how we feel about this new turn of events or the potential onslaught of new support needs by users of SQL Server, there's not much we can do about it. The proverbial cat is already out of the bag.

 

Whether the necessary patches are included in the core PostgreSQL code or not, AWS Aurora, at least, will still offer this functionality as a service. I believe this means that over the next 2-4 years, the community will grow from a base of users that have a lot of database experience but have little footing for how to approach a similar, but different, database. And regardless of how we feel about the new demands, this will put on this community, it's a group of people that still want to do their job well and contribute back to the community.

Why do I care?

So, why do I care? Well, if you were to put my 20+ years of database experience into a word cloud of sorts, SQL Server would occupy the largest portion of space. For nearly 15 of the last 21 years, I was primarily a Microsoft data platform user. And while PostgreSQL has occupied the second largest (and longest) portion of my database landscape, I really came of age as a database professional within the SQL Server community. In fact, since coming back into the PostgreSQL community almost 4 years ago, I've continued to look for ways to foster a community and learning modeled after what I knew and experienced through SQL Server and the Professional Association of SQL Server (PASS) community. And I can say, without a doubt, that I'm not the only one looking for the same thing.

 

Let me ask you something then.

 

When was the last time you had to join a new community?

 

Is the first thing that comes to mind a technical community (data, programming language, visualization tools, etc.) or something else? Whatever community that was, how did you feel after first stepping through the proverbial door?

 

Did you have a crowd of people ready to cheer you on, eager to see you succeed, and ready to support you?

Or, did you feel like an outsider looking in, trying to figure out how to find the right help, from the right people? Did you feel like everyone else always knew how to connect with the people around you but you struggled to find comradery and resources?

Depending on where you fall, what could have made it better for others or for yourself?

 

Let's bring this same thought experiment a little closer to home. What about the PostgreSQL community? What was your "onboarding" experience like and how does that compare to some of the newest members you've met recently?

 

It just so happens that we have some feedback from the larger community based on The State of PostgreSQL survey Timescale orchestrated this past April. There were 500 respondents that ranged in experience levels from novice, newly joined developers, to users with 20+ years of experience. Of those 500 respondents, 49.5% have used PostgreSQL for 5 years or less, and 50.5% had PostgreSQL for 6 years or more.

It would make sense, then, that about 50% of the survey participants felt like it was a bit difficult to use PostgreSQL and get involved with the community.

And yet, the other 50% of participants seem to have a very different experience with PostgreSQL the longer they stay connected.

The real goal, then, is to determine ways to improve the user experience within the PostgreSQL community earlier in the cycle, rather than hoping folks stick around for more than 5 years so that they can begin to have a more positive outlook on the community at large.

 

As a Developer Advocate at Timescale, one of my primary responsibilities is to engage with the PostgreSQL community so that we can figure out how to tackle these issues head-on. I'm excited to contribute to the efforts, learning better methods to teach people how to use this technology well and help them be successful.

 

And, as a former SQL Server professional and community member, I want to prepare for what I believe will be a growing number of database professionals joining the Slack channel, Twitter conversations, and conferences trying to improve their craft and give back to the community.

 

To do this, we have at least two options in the months and years ahead.

 

The first option is to take sides. Unfortunately, this happens all too often in technical communities. Whether it's a database engine or the newest development language, this approach is an option. "We're better! You're not!"

Or… we could choose to just sit around the table, share a meal, and learn from one another about how we can build a better, shared community based on the best parts of what each community offers.


Quite honestly, we could ensure that we're treating the community more like our beloved namesake - Slonik the elephant.

It turns out that Elephants are close-knit communities. They care for each other, they actively accept orphans and elephants that are in need, and they're generational - passing down knowledge and community expectations from one generation to the next. Not a bad example to follow, right?

 

Five initial options for building a better PostgreSQL community

Let me present you with 5 quick, high-level thoughts on ideas we could reuse from the SQL Server community that might begin the process of improving participation and engagement.

(1) Lead with empathy and curiosity

What does it mean to lead with empathy and curiosity? When the posture of the community starts with empathy, it means that we remember what it was like to be new to a community ourselves. When we start conversations from a place of curiosity, we avoid choosing sides and instead join new users where they are. Here are a few things to keep in mind in regards to the SQL Server community that might start to show up in greater numbers soon, although I think these are good things to remember regardless of the user.

 

Expect confusion from users that already know SQL. Oftentimes these users honestly don't know that the dialect of SQL they've been using (T-SQL in this case) isn't a standard. They know concepts but not direct comparisons to the SQL standard or pl/pgsql.

 

Remember that you were a newbie once. Remember when I asked you to think of the last new community you joined? ;-) 

 

Assume positive intent and that they have tried to search out a solution first. Again, many users coming from the SQL Server community have a good network of people and resources they've grown accustomed to (we'll touch on that next!). But that community has also fostered good habits for finding solutions and asking better questions. Assume the best!

 

Prepare resources to meet their specific needs. This doesn't mean that we craft all documentation, blogs, and help forums for a specific user base. But, if we know many people will be joining this community with the same understanding of a feature or topic, we can provide them a better foundation for transferring their knowledge into PostgreSQL. It would reduce support overall and foster better community involvement.

 

Let me give you one really simple example from my own experience (and that of many SQL Server users that try PostgreSQL for the first time).

 

It is a common practice in nearly every T-SQL script I've written, seen, or used to create and use variables and control logic directly in the flow of a script. Because all SQL is executed by default as T-SQL, there is no need for code blocks to do data-specific logic. This really simple T-SQL example is incredibly common in the day-to-day workflow of a SQL Server DBA or developer.

In PostgreSQL, however, I can't do this in the midst of my migration scripts or maintenance tasks directly. This was a constant source of frustration for me during the release of my first feature at a new company that was using PostgreSQL (but had very few developers that understood databases). I knew what I wanted to do, but I couldn't get any IDE or migration script to do what I wanted.

Eventually, I found a post that talked about anonymous functions within a SQL script for ad hoc processing. Although I didn't like the added complexity, I could finally write my migrations correctly.

Having proactive examples in the documentation that acknowledge this difference could be a game-changer for developer success.

(2) Lower the bar for entry-level #pghelp

More than 10 years ago, someone in the SQL Server community had the idea of using #sqlhelp  Twitter hashtag to provide help. At the time, the size limit for a tweet was 140 characters so they understood it could only provide short, really succinct triage-like help. In some ways, I think this limitation has actually helped the community learn how to ask better questions that will draw valuable answers. This is evidenced by two things in my opinion. 

 

First, not every question gets an answer. It's a community-led initiative and so the quality of the question and respect for the "free" nature of the help influence overall engagement. And second, the SQL Server community actively protects the use of this hashtag. That's not always taken kindly by outsiders, and I'm not even sure how much I agree that a community can "own" a hashtag, but it produces valuable community around a specific technology that has proven to be helpful for thousands of users over the years. 

Like the PostgreSQL community, SQL Server users also have a community Slack channel that is active and more long-form. But today, more than 10 years after the community started using it, #sqlhelp is an active channel of connecting with the larger community to give and receive timely help.

 

Could we do something similar with a #pghelp hashtag?

 

(3) Support new members by cultivating more leaders

As the PostgreSQL community grows, we can only support users if we build a growing group of leaders. A few of the leaders in the SQL Server community realized this same need over a decade ago and proactively sought ways to build new leaders, content creators, and community advocates. One successful example of this is an initiative called "T-SQL Tuesday", a worldwide monthly "blog fest".

 

The idea is simple. Each month, someone volunteers to be the host, they announce the topic at least a week in advance, and then anyone from around the world can contribute to the conversation by publishing a blog on that topic. Some of the topics are technical (replication, HA, query tuning success), while some are more soft-skill-focused (best/worst SQL interview experience, how to avoid burnout in the SQL field).

 

As I said, it was specifically started as an initiative to get more people in the community to contribute to the conversation. Of almost any initiative that this community has undertaken in the last 10-15 years, T-SQL Tuesday has done more than anything else to cultivate new community leaders, alter careers, and bring collaboration across the globe. The most intriguing part of this for me is that it's free to run and participate in, and Microsoft has had nothing to do with it. It is completely community-led. 

 

Starting in April 2022, a few PostgreSQL community members are going to start "PSQL Phriday", a monthly community blogging initiative. To learn more about it, the monthly topics, and how you can participate, watch the blogging feeds at planet.postgresql.org and monitor the #psqlphriday on Twitter. I'm excited to see this get started and can't wait to learn from many others in the community!

 

(4) Seek leaders proactively

As new members join the community and it grows, many of them will come with a desire to contribute in some way. Some of that has happened in meaningful ways around tooling that have dramatically improved the day-to-day tasks of every SQL Server DBA.

 

One of the best examples of this in recent years has been the DBATools project. This is a PowerShell toolkit of hundreds of commands that can help backup a database or migrate an entire cluster of servers, no UI necessary. It is heavily supported by the community and they're always looking for opportunities to grow, learn, and contribute. Finding these developer-focused initiatives could be a great way to enlist help and add additional support resources as the community grows.

 

(5) Develop Consistent messaging around community

Lastly, I think it would be helpful to consider ways to consistently articulate the best methods and practices for accessing help within the PostgreSQL community. Although the Community page on the PostgreSQL.org website does list many avenues for getting help, it still requires a fair amount of cognitive load to figure out which avenue is best suited for a given need.

 

  • When do I use the email lists? What if I don't want to subscribe long-term?
  • If I join the Slack channel, how do I best ask for help? Can I mention specific people to try and get help? Create new rooms?
  • Why would I use IRC or Discord over Slack?
  • Is there a #pghelp Twitter hashtag, and if so, what kind of questions are best asked there?

 

As a new user in the PostgreSQL community, I wanted this kind of guidance because I didn't want to overuse a resource or direct questions to the wrong group of people. If we had more consistent guidance on how to interface with the community across the plethora of channels, then other leaders within the PostgreSQL community could give the same consistent message. I appreciate how leaders like Brent Ozar, a leader in the SQL Server community, doesn't feel obligated to answer every question thrown their way. They have clear instructions on their blog that describe the best ways for someone to actually get effective help and they often direct them there. "Hey, thanks for reaching out. That sounds like a great question for #sqlhelp. Check out this link for instructions on how to use it!"

 

When people feel heard, they're more likely to stay connected and involved. Even if the answer often points them to good documentation of how to get help, they're still acknowledged and included.

Wrap up

I'd like to leave you with a small twist on a common adage.

 

"You can't pick your family… but you can influence who becomes your friends." 

 

As this community grows, are we prepared to provide some new ways of engaging with them? These specific ideas might not all fit within the PostgreSQL community, but I'd be interested to hear your thoughts about ways we can better incorporate the skills and talents of the community we already have to prepare for the future. Feel free to reach out to me on Twitter (@ryanbooz), through email (ryan@timescale.com), or in our Timescale Slack channel (https://slack.timescale.com).


One last thing! The 2022 State of PostgreSQL survey will open later this spring. Take some time to review the results from last year, and then sign up at the bottom of the report to be notified when the new survey is ready. The more feedback we receive, the better we can understand our community, what's working well, and what can be improved in the years to come.

 

PostgresConf Organizers     March 28, 2022

Due to a rise in concern around the Omnicron variant of COVID-19 and surprise remodeling/construction from the Hilton, Postgres Conference Silicon Valley 2022 has been rescheduled. The hotel has been apologetic and accommodating. The new dates for the conference are:

April 7-8 (Thursday - Friday)

Though this was an unexpected decision, we are confident that the delay of the event will result in a positive outcome for all involved.

Thank you for your support!

Get your tickets here.

Joshua D. Drake     January 05, 2022

Invisible Disease Awareness

“According to the Disabled World website, an estimated 10% of the U.S. population has what could be considered an ‘invisible’ disease, defined as a health condition that causes significant impairment and undermines the overall quality of life but does not outwardly manifest itself in ways that are apparent to others.” [1]



While normally our focus is Postgres, we wanted to take a moment to bring attention to the People side of People, Postgres, Data. May is mental health and Ehlers-Danlos awareness month. Ehlers-Danlos Syndrome (EDS) is a rare condition that affects the collagen throughout the entire body, resulting in dislocations, subluxations, lack of joint stability and support, tendinosis, and debilitating pain. There is no cure and the symptoms are life long.

 

In 2020, PostgresWarrior (AKA Amanda Nystrom) was diagnosed with Hypermobile EDS and Fibromyalgia. She is an instrumental and invaluable member of the People, Postgres, Data community. She has driven us forward in ways that so many of us never see and yet require to succeed. Many of our community are affected by invisible diseases - let's take a moment to appreciate what they accomplish and fight for in Postgres/Open Source.

Upcoming webinars | RSVP here

  • May 25, 1pm ET: Creating a Resilient PostgreSQL Cluster with Kubegres

  • June 15, 1pm ET: When it All Goes Wrong - Incident Response in Large Postgres Databases

  • June 23, 1pm ET: Making Postgres Fly on Kubernetes

  • June 29, 1pm ET: Implementing Cluster File Encryption in Postgres

24x7x365 Postgres & Linux servicesCommand Prompt, Inc.The last of the original Postgres companies

Sponsored

Community Chat

Our Discord Channel has 2000 community members waiting to participate in your Postgres success. Join us today with a community that has rule #1 of: Be Nice.

Podcasts








  1. https://www.socialworktoday.com/archive/072417p32.shtml
Joshua D. Drake     May 19, 2021     eds postgresql

With 2020 firmly in the rear view mirror, it is time to look forward and down the highway of 2021. The organizers of People, Postgres, Data have gathered over chat, email, phone, and even a few socially distant, in-person events to determine a strategy for continuing as the most influential and positive community for all things Postgres related.

Sad face

The goal is to resume in-person events. However, out of concern for the health and comfort of our global community, we have made the decision not to host any in-person events until Q4 of 2021. We are prepared to wait until 2022 if that is what the health officials recommend. We know that many will find this news disappointing and we are working diligently to ensure that the health and education of our community is the top priority.

Happy face

We are continuing our popular webinar series, adding new presenters with pertinent content for all of our attendees. We will be adding more professional development and data problem solving topics to our library, and we will no longer be limiting education to just Postgres, as many data and human problems are neutral in the particular platform we happen to enjoy. If there’s a topic you’d like to present or see, we’d love to hear from you!

RSVP for upcoming scheduled events

  • January 26, 1pm ET: All we need to work with SQL is SQL
  • January 27, 1pm ET: PostgreSQL Forks and Knives
  • February 3, 2pm ET: Postgres for SQL Server Users
  • February 4, 1pm ET: Configuring PostgreSQL for Faster Analytic Query Performance
  • February 23, 1pm ET: Blockchain as a Database

Ecstasy 

Postgres Conference 2021: Digital will be happening in May of this year! An overwhelming feeling of great happiness and excitement has our dopamine pumping, and the whole People, Postgres, Data team is basking in it. 

 

As an all digital conference, we will offer a similar environment to what our community has come to expect: best in class content, professionalism, and top-tier educational opportunities for all who attend! Keep your eyes peeled over the next few weeks for more information on speaking opportunities and how to attend!

Joshua D. Drake     January 20, 2021

We all know that we should produce good documentation, but we’ve all skipped out on it every now and then. It’s often a lot of  mundane effort when you could be doing new exciting things.

 

Then days, weeks, months or even later the questions start coming in from your team-mates or new hires: why is this column like this, what does this column really describe etc. You no longer remember and you have to spend time to understand the database you’ve made.

One of the great things about PostgreSQL is that documenting your database is a piece of cake and that it saves you more time than you spend on adding comments. It’s without exaggeration less time consuming per table than answering a single question like the ones above.
Thankfully the syntax isn’t horrible and adding comments won’t be a slow affair if you have a lot of existing data unlike some other DB engines I’ve worked with.

PostgreSQL has support for storing comments directly in your schema:
You can add a comment to a table, a schema, an operator and so on.

 

Adding them is simple:

 

COMMENT ON TABLE mytable IS 'This is my table.';

COMMENT ON COLUMN my_table.my_column IS 'Employee ID number';


Some tools have better support for showing them than others and I hope to see that being improved in the future, for instance: Datagrip, my editor of choice will not show comments in the database explorer unless you hover over the object it does include it in the in-editor information pop-up when hovering over a column, function or table.


My personal favorite for generating visually pleasing documentation with little effort is SchemaSpy it requires Java and the JDBC driver to run and it generates pretty documentation in about a minute for a complex schema:

java -jar "/home/me/database/tools/schemaspy-6.1.0.jar" -dp "/home/me/database/drivers/postgresql-42.2.16.jar" -t pgsql -db postgres -s SCHEMA_GOES_HERE -host localhost -port 5432 -u USERNAME_GOES_HERE -p PASSWORD_GOES_HERE -o "/home/me/database/documentation/" -hq  -nologo -vizjs


The output is in the form of a relatively pretty website like this : Sample

I would say that this is quite a few levels of quality above what most companies have for their internal databases and with a lot less effort. As you can see from the sample it even supports markdown.

 

If you have suggestions for even better tools for the job, please join the People, Postgres, Data: Discord server

This work is unrelated to my job at Bamboo Solutions AS

Magnus Brun Falch     January 07, 2021

With the pending GA release of Star Link, more cities adopting municipal WIFI, and the growth of remote work due to the pandemic, one would assume that cell phone providers would be falling hand over fist to provide quality services at a quality price. Unfortunately this is not the case and it is hurting the future of our workforce.

Carriers currently think that 30GB of Hotspot data is enough for the average digital nomad. While that may have been the case previously, it isn’t any longer. There is a hundreds-of-thousands-strong workforce specializing in Information Technology, Digital Design, Web Development, and other creative industries. They are living, working and adventuring in RVs, Sprinters, Skooolies (pictured), and other vehicle dwelling options. This community is nomadic by design and should not be artificially limited by technology. 

 

Why is it that we are being charged so much money for so little? Outside of two providers announcing rural initiatives, we are still acting like data needs are small and that they come at a quality price. Data is ubiquitous; it is the new water (for getting work done). In the new economy workers need faster, higher quality, and unlimited amounts of data to get their job done.

 

Where could you go and what could you experience if you weren’t tethered by the faux limitations of bandwidth?

Resources

Featured Content

Joshua D. Drake     October 13, 2020

By Magnus Brun Falch CoFounder of Bamboo Solutions AS

From zero to PostgreSQL extension in three hours.

I recently had a personal side-project which included setting up a working REST backend for a mobile and web application. There were numerous challenges to overcome but my available hours to work on them were limited. I had a few evenings to spare on this project and didn’t feel like writing a lot of boilerplate in C# to achieve it.

A trusted friend had praised PostgREST many times. My testing showed it outclassing ASP.NET Core for all my test cases by an order of magnitude, half a year earlier.
I finally had a chance to use it as the base for my API layer in one of my projects.

One thing that this project called for which would not normally be easy to achieve using PostgreSQL alone, is to pre sign requests for an S3 compatible storage platform. I had 6 hours left in the budget for this feature, after all the firm requirements were estimated.

I didn’t want to write a full implementation of the relevant parts of the S3 spec from scratch or using pgcrypto. My first instinct was to have a look at the different procedural languages available in PostgreSQL, some of which are Tcl, Java, JS, Python and Julia. None of them were too tempting at the moment.

Luckily I was an early member of the new People, Postgres, Data: Discord server and there are some very interesting and clever people there, Eric Ridge, the main author of ZomboDB (ZDB) among them.

I’ve kept an eye on ZDB for years after doing some research into ElasticSearch. My project included text search so I relished the opportunity to chat with him. Among our many topics of conversation were the upcoming release of a new Rust based version of ZDB and its underlying framework: PGX. I asked him about whether he thought PGX would be a good fit for my remaining challenge. He said “Absolutely”. I spent an hour setting up an Ubuntu VM with all the needed tooling & dependencies including building and testing the “hello world” example. A thorough reading of the man page would likely have saved me half an hour.

The next 30 minutes were spent identifying the most promising Crate to use. Within three hours of writing the first line of code I had a working plugin. About 80% of the time spent was lost to unfamiliarity with the language and writing it using nano over ssh instead of setting up a proper IDE like Jetbrains CLion. I also struggled a bit with finding the correct way of extracting the value from a result of an async function in a foreign language.

In total I spent 4 hours and 25 minutes from the time I started the fresh Ubuntu 20.04 server I was going to use as a Dev environment, to having a working build of an extension. It can be called inline in PostgreSQL to sign download requests in less than 1ms on my Intel I5 2500 testbed.

 I’ve had zero experience with Rust and have never read any teaching materials or looked at any tutorials for it before that evening. What I’d heard about Rust previously was that it’s really fast, and that the compiler would yell at you until your code is of acceptable quality.

Example of the PGX simplicity:

#[pg_extern]
fn pgx_s3sign_pre_get(
  server: String,
  input_bucket: String,
  input_identity: String,
  input_secret: String,
  input_file: String,
  duration: i32,
) -> String {
  let bucket = bucket_create(server, input_bucket, input_identity, input_secret);
  let url = bucket
      .presign_get(input_file, duration.try_into().unwrap())
      .unwrap();
  Url

 

The extension was merely for internal use in a specific project and has some rough edges. It is published on GitHub and needs some more polish before I would consider it a production ready extension. Pull requests are welcome if you have suggestions before I get the time to work on it some more.

 

Notes:

  • PGX is a framework for writing PostgreSQL extensions using Rust.
  • ZomboDB integrates Elasticsearch and PostgreSQL.
  • PostgREST consumes a PostgreSQL schema and generates API endpoints.

This work is unrelated to my job at Bamboo Solutions AS

Magnus Brun Falch     September 28, 2020     extensions zombodb postgres rust postgresql

What’s your view?

Over 25 years ago I got into an argument with my boss. He was frustrated with all the tasks that needed to be completed and feeling overwhelmed. I said, “Hey, why not go to a park and take in the scenery? You could work there too.” Those were the days before the Internet was required to complete your day to day. He was incredulous, “I don’t pay 1200.00 a month for an office to go work at a park.” It is funny how a single conversation can stick with you throughout life. Now that person is in the Cannabis industry and takes a completely different view on life.

 

Today I write this newsletter from Henry’s Lake, Idaho just about 30 minutes from Yellowstone National Park and the newsletter image is a photo I took this morning as I was about to make coffee. During these trying times with the pandemic and economic uncertainty it is vital that all of our community take a moment to reflect on what their view is. How is it that you are living your life? Are you putting people first? Are you helping each other as you move through the day? Are you in need of help? These are all questions we should ask ourselves and others every day.

 

With People, Postgres, Data we make an earnest effort to put people first, professionally and personally. This is why when we have physical events, we have tracks that are not traditional PostgreSQL faire including our Career Fair and Professional Development and Leadership tracks.It is also why we try to keep our digital events free. The better people we are, the better professionals we can be and the better the professional we are, the more we are able to help people. It is also why we started a new community chat server with Discord. Though the server is there to help you with Postgres, it also exists to embrace community with channels such as #watercooler, #food, #games and #professional-advice. It is a holistic approach that allows people to be people, not bytes.

 

RSVP for upcoming free digital Events

  • September 29, 10AM PST: Introduction to PostgreSQL ColumnStore Indexes

  • September 30, 10AM PT: Live Demo: Creating A Single Point Of Access To Multiple Postgres Servers Using Starburst Presto

  • October 6, 9am PT: Data processing more than billion rows per second

  • October 7, 10am PT: Database Isolation Levels, Data Issues and Global Transaction Consistency

  • October 14, 10AM PT: Live Demo: Unlock Data In Postgres Servers To Query It With Other Data Sources LIke Hive, Kafka, Other DBMSs, And More.

  • October 20, 10AM PT: PGX: Build Postgres Extensions with Rust

  • October 21, 10am PT: Using PostgreSQL, PostGIS, and pgRouting for street sweeping

  • October 27, 10AM PT: Logical Replication lessons learned for the Data Warehouse

  • October 28, 10AM PT: How to build local communities: a meetup perspective

  • November 10, 10AM PT: CYPEX: Revolutionizing PostgreSQL Application Development

  • November 12th, 10am PT: Blockchain as a Database



Joshua D. Drake     September 22, 2020

Adaptation Lizard

As Postgres Conference pushes forward in the brave new world, we evolve and increase the ability for the People, Postgres, Data community to succeed. As a part of our positive adaptation we have a new website that features upcoming events, professional content (written and video), and the best in our written community via “Community Content”.

Discord

In an effort to provide a modern, friendly, and inclusive community platform, we have launched a Discord server for all things Postgres. We are providing a helpful experience with rule #1 being: Be Nice. Our discussions will branch out beyond the core of PostgreSQL and provide a forum for success with Postgres and related technologies. Join us for what is guaranteed to be a refreshing experience for the community: https://discord.gg/tjxNBCz

2021

We are seeking feedback from our community on 2021 in-person events. We are currently considering the East Coast event for October 2021 and the West Coast event for December 2021. Please help us in determining the type of event you would like to participate in!

Upcoming live events

We currently have the following webinars scheduled through October:

Joshua D. Drake     August 25, 2020
Audience 945449 1920

 

Like most conference organizers we are learning to adapt to the new world; a world where physical events are no longer viable (at least in 2020). A world where people are genuinely and realistically concerned that an in-person event would increase their chances of receiving or spreading a life threatening virus.

 

The question is: Are in-person events a thing of the past?

 

The answer to that question is a difficult one. Our friends at O'reilly and Associates have permanently canceled their in person events. Our friends in Europe recently canceled the well respected PgConf.EU and Ibiza. We had to cancel our 2020 marque event in NYC in March and our upcoming Silicon Valley conference. The local community organizer website Meetup.com has even modified their capabilities to allow for online meetups. 

 

Humans in general seek out fellow human contact. That contact is usually of reasonably like minded individuals or at least mutual interests. This is why events like Postgres Conference are successful, because irrespective of any personal beliefs we are all there to learn and enjoy fellow Postgres professionals. But are virtual meetups and conferences going to be enough to satisfy that connection or are people going to demand a return to a historical norm?

 

Challenges

Even before COVID-19, in-person events came with challenges that put significant pressure on volunteers. Between cultural communication differences, having an independent Code of Conduct committee, pricing, economies of scale, partner demands, and now social distancing, conferences are now going to be more complicated than ever. A room that once could comfortably seat 100 can now only properly sit 30. An exhibit hall is likely out of the question and one-on-one mentoring and networking are likely not going to be viable.  How do we work around these limitations? Is it worth it? Are the people in our community even interested anymore or is it time to accept a new norm?

Opportunity

Without question this is a time of reflection, continued development of relationships, and looking into the magic 8-ball; a continual asking of questions to find the right path forward. The pandemic is a tough foe but true leaders are looking forward and trying to find ways to continue to serve. For that to be successful we need your help. We have put together a poll (that can be found here) to gain insight into what opportunities we may be able to pursue in the future. Please take a couple minutes and help shape the future of Open Source events. 

 

As a closing, we are actively moving forward with Digital Events across the globe and have an unending Call for Presentations open for Webinars. If you have any feedback or brilliant ideas, please send them to us via organizers@postgresconf.org.

 

Blatant Poll Link 

Joshua D. Drake     July 17, 2020

Latest Posts

  • The future of community in light of Babelfish (adapted from PGConf NYC 2021 Keynote)   Ryan Booz Director, Developer Advocacy Timescale Twitter: @ryanbooz Email: ryan@timescale.com On Dec...
  • Due to a rise in concern around the Omnicron variant of COVID-19 and surprise remodeling/construction from the Hilton, Postgres Conference Silicon Valley 2022 has been rescheduled. The hotel has be...
  • Invisible Disease Awareness “According to the Disabled World website, an estimated 10% of the U.S. population has what could be considered an ‘invisible’ disease, defined as a health condition tha...
  • With 2020 firmly in the rear view mirror, it is time to look forward and down the highway of 2021. The organizers of People, Postgres, Data have gathered over chat, email, phone, and even a few s...
  • We all know that we should produce good documentation, but we’ve all skipped out on it every now and then. It’s often a lot of  mundane effort when you could be doing new exciting things.   Then ...