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:
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.
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.
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.
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.
Not a very exciting answer, but time. There just aren't enough hours in the day to fit everything in.
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.
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.