Start trial

    Knowing the difference between Developer skills and Support skills is crucial when faced with mission-critical situations.

    A developer friend and I had a discussion over coffee the other day. After the usual techie talk, he asked, “Why would anyone want to pay for external PostgreSQL support when the Dev team can work through any database problems themselves?”

    I asked him to clarify what he meant.

    He pointed out that the Dev team at his workplace created the database and schema they use in production. So, he reasoned, surely they would know the system better than anyone outside the organization, and would therefore be better placed to fix issues themselves.

    I agreed with him - the Dev team would know that database, schema and tables very well. Support isn’t really there to advise on the names of columns, or to debate how a database should be constructed. So from that point of view, external Support probably wasn’t necessarily required.

    However, I noted that there are many aspects of PostgreSQL that are crucial to the ongoing performance and availability of a database about which a Dev team may not be familiar.

    To illustrate this point, I asked him some in-depth questions, such as: Where would the tablespaces sit for best performance? How would the Dev team deal with a huge table – one with millions of rows? When was the last autovacuum run on each table? What would the Dev team do if everything suddenly started running slowly even though things had been running just fine only moments before? And so on.

    He didn’t have any answers.

    He didn’t know what the system tables were and he thought autovacuum just ran “once in while in the background when needed”. This is mostly right, but understanding what the triggers are for autovacuum (and why it might not run) can be important when things start to slow down. I didn’t have a problem with his lack of detailed knowledge as my friend is a great developer, not a DBA. I also asked him how the Dev team would deal with patching, upgrades, replication and so on in a production environment, and what would they do if something went wrong in any of these areas. He couldn’t answer these questions either.

    This brought me to the most important issue – costs to the business. “How many of your Dev team really understand how the internals of the database work?” I asked. “If you’re lucky, it might be one or two. But do they really have the skills to diagnose problems in a mission-critical situation? Now think about the other Dev team members who are sitting around doing nothing (costing the organization real money), while they wait for the most knowledgeable Dev team member to fix the database.”

    By the end of the conversation my friend accepted that external expert Support was worth having. I also agreed with him that Support is not really there for assisting Dev teams with database/schema/table decisions. Essentially, we agreed that each team was most suited to look after their own areas of expertise for the best, and most cost effective, results.

    To discuss these issues in greater detail, contact the PostgreSQL team at Fujitsu Australia Software Technology.

    Topics: PostgreSQL support, Fujitsu Enterprise Postgres, Enhanced enterprise open source database, PostgreSQL development

    Receive our blog

    Fill the form to receive notifications of future posts

    Search by topic

    see all >

    Read our latest blogs

    Read our most recent articles regarding all aspects of PostgreSQL and Fujitsu Enterprise Postgres.