I’m often asked what do I think the future for Postgres holds, and my answer has been mostly the same for probably 8 years now, maybe even longer. You see for Postgres itself stability and reliability is core. So where does the new stuff come from if it’s not in the stable core… extensions.

Extensions within Postgres are unlike most other databases allowing you to modify or well extend the standard Postgres behavior. You can build other storage backends, new types, etc. Postgres itself ships with a number of extensions within the “contrib”. The list of contrib extensions hasn’t changed any time recently, but even contrib is a small sampling of what is possible. Beyond core there is a whole world of extensions, I want dig into just a smalls sampling starting with a few in core…

If you want to seem like the smartest person in the room, wait for a break in conversation, after sitting quiet for 15 minutes, and ask “What problem are we trying to solve here?" It works every time.

What do I mean by trick/hack? This can be super flexible, but I’ll toss out a few of my own personal ones.

One of the rules of my product management philosophy, is if you’re going to use a tool or trick then use it often. This is in fact one of my favorite interview questions for PMs. If you ever interview with me, be prepared it’s coming. It applies for engineering managers and others in leadership roles as well, but I’ve found especially get for PMs.

7 years ago I left Heroku. Heroku has had a lot of discussion over the past weeks about its demise, whether it was a success or failure, and the current state. Much of this was prompted by the recent, and on-going security incident, but as others have pointed out the product has been frozen in time for some years now.

I’m not here to rehash the many debates of what is the next Heroku, or whether it was a success or failure, or how it could have been different. Heroku is still a gold standard of developer experience and often used in pitches as Heroku for X. There were many that tried to imitate Heroku for years and failed. Heroku generates sizable revenue to this day. Without Heroku we’d all be in a worse place from a developer experience perspective.

But I don’t want to talk about Heroku the PaaS. Instead I want share a little of my story and some of the story of Heroku Postgres (DoD - Department of Data as we were internally known). I was at Heroku in a lot of product roles over the course of 5 yrs, but most of my time was with that DoD team. When I left Heroku it was a team of about 8 engineers running and managing over 1.5m Postgres databases–a one in a million problem was once a week, we engineered a system that allowed us to scale without requiring a 50 person ops team just for databases

This will be a bit of a personal journey, but also hopefully give some insights into what the vision was and hopefully a bit of what possibilities are for Postgres services in the future.

A few months ago there was a tweet from @jasoncwarner about leadership skills/super powers:

• SQL
• Excel
• Concise writing
• Story telling
• Prioritization.

I’ve spent quite a bit of time in product management roles, and in recent years more in leadership. I’ve found a lot of the skills in product to translate into good leadership skills as well, but maybe I’m bluring the lines there. Regardless, with his 5 skills I found myself nodding and have written about each of these some on my blog and then at times on twitter. He long since deleted the tweet, and while I wait for him to republish I thought I’d reprise a few of these with my own view point.

At past jobs I’d estimate we had 100 different production apps that in some way were powering key production systems. Sure some were backend/internal apps while others key production apps such as the dashboard itself. At other companies we had a smaller handful of Heroku apps that powered our cloud service, about 5-10 in total. Even just working with those internal apps it’s a number of things to keep context on. But when it comes to interacting with something you don’t know getting a lay of the land quickly is key. In helping a customer optimize and tune, or even just understand what is going on in their app an understanding of the data model is key.

As I just started a few months back at Crunchy Data I found myself digging into a lot of new systems and quickly trying to ramp up and get a feel for them.

One of my most fascinating work experiences was going through the spokesperson certification process at a large tech co. This isn’t some rubber stamp virtual training to not use profanity on stage type training. This is the training they would give to any executive before you were greenlit to talk to press. When I say press I mean Techcrunch, but also Bloomberg, or Jim Cramer, or any major big brand news outlet.

As a product manager over a specific product line I knew my product well. Put me in front of an unhappy customer and I could lay out our roadmap, listen to their questions, take product input, and get them to a happy place. But this wasn’t about my product (only). A person with the spokesperson stamp could be asked any question about an entirely other area fo the company. You had to know every recent product launch, all the key metrics, know where traps may lie, and you had to land the core company messages in addition to the ones you cared about. To study you received about 100 pages of a powerpoint presentation that had key releases from each product, key numbers, customer stories.

I think back to my time in college, and I learned some valuable things. I also learned some incredibly worthless things (i.e. don’t flip a car upside down and then backover… it’ll break the axle so you can’t roll it). Even in classes… the basic approach to a supply/demand curve to maximize profit is cute when done in a classroom vs. the complexities of how things actually work… I mean I get the idea behind it, but what you learn is so far being able to be translated into being usable. But what surprises me looking back was a couple of skills around running meetings that I find so rare in the workplace that have immense value.

I’ve always been fascinated at the intersection of business and technology. I’d been coding for a long time before college, and while interesting it was also a means to an end. When you combine technology with business you can solve things in entirely new and valuable ways. My major was management information systems, and all folks in my program came out with a computer science minor in addition to their business degree–something pretty rare for more MIS majors in other programs and well generally for anyone coming out of a business school. Perhaps I’ll get into the value of CS training even if you aren’t looking for a CS job some other time.

Within the program we would have a senior project that was actually a real world project for one of the large companies that sponsored part of the program. We’d have monthly reviews with the company stake holder. We’d also have weekly meetings, these were especially well run. There were really 3 items that made them especially efficient.

I’ve been at dinners before with developers that admitted developers, themselves included, can be a bit opinionated. In one case one said for example, “I love Postgres, but I have no idea why.” They were sitting at the wrong table to use Postgres as an example… But it is quite often that I am asked Why Postgres.

In fact a little over a year ago good friend Dimitri Fontaine asked if he could interview me for a book he’s working on for Postgres. I’ve long said their is a shortage of good books about Postgres and he’s done a great job with his in providing a guide targetted at developers, not just DBAs, that want to become better with their database. What follows is the excerpt of the interview from the book. And if you’re interested in picking up a copy he was friendly enough to share a discount code you can find below.