As a young university student, one of my favourite times of the year was when my first car was due for a service – any excuse to take a break from the books. I would look forward to parking her in the driveway and getting started with the inevitably messy task of restoring her back to health. As life moved on, I eventually succumbed to the fact that I just wouldn’t have the time, nor the know-how, to service every car I would subsequently own. Besides, that’s what certified engineers and maintenance plans are for.

Now, many years later, in my role as a Business Development Manager at RadixTrie, I have come across several customers that are seemingly faced with the same problem as the 19-year-old me.

Through my interactions with clients and potential clients, I've noticed an increase in companies adopting an open source software strategy and moving away from proprietary software vendors. The stats back it up too – according to GitHub BCG Analysis, 99% of Fortune 500 companies currently use open source software.

This rapid shift in the technology landscape can be attributed to the appeal of community-led technology. Some of the factors that make these technologies so appealing include:

• Low barriers of entry with access to free platforms;
• Lower licence fees;
• Enterprise-grade open source options providing high levels of:

i. Performance;

ii. Security; and

iii. Functionalities.

• Support flexibility and agility – multiple vendors with support subscriptions and community-led functionality changes; and
• The opportunity to tap into the open source community for collaboration.

With this said, the appropriate research and planning are required to account for what lies ahead for every open source journey. Here’s an example of how we’re typically seeing customers dive into the world of open source:

At first, the appeal for an alternative database platform, such as PostgreSQL, is compelling. It can sufficiently take on the database function of a new or peripheral business application, and it requires no licensing (and, therefore, no software cost) upfront. The early benefits are apparent right from the start as the functionality and features, along with dependency on the platform, grow. It doesn’t (initially) appear to be difficult to manage the environment, and the current in-house skills are quite capable as very little maintenance is required. Initially, this becomes the responsibility of the developers who created the application.

Over time, as the application evolves, the database platform forms the foundation a now critical application, which is core to the business and requires a significant amount of love and care.

This evolution is owed to several factors, including:

• The advancements in the application features; and
• The increase in the variety and volume of data being captured over time.

Inherently, this increases the risk of ensuring that the database remains performant, stable and secure. Developers are good at crafting new solutions and have a passion for fixing problems with code. So when they perform very methodical and disciplined database support and maintenance, it can easily lead to:

• Slow databases or database stability problems;
• Delays in development deliverables, since database outages are not scheduled and take a long time to resolve;
• Demotivated developers; or, worst of all
• Negative career impact.

The 19-year-old me would have been in big trouble if I was left to fix the brakes on my car. In much the same way, organisations face an increased risk when they don’t have specialists to assist with mission-critical application components such as databases.

One day, a realisation occurs – you need database support levels that your in-house application development team simply cannot provide. When your key developer is too busy indexing a database to focus on his primary responsibility, ie, application features, you know you have a problem… ultimately, the PostgreSQL database outgrows the in-house skills that need to support it.

At this point, you need to ask yourself the following questions:

• What is the risk to the business if the database is down?
• What are my primary needs for my database environment/s?
• Am I using the database to its full potential?
• Can we afford to have other non-DBA resources managing the database?
• Is there a structured continual improvement process applied to the database?

Yes, it is possible to support a new database platform in the early stages of its life cycle. However, it is important to keep in mind that the database environment will eventually mature and require a deeper level of support and understanding to manage it.

At this stage, consider a partner with the necessary domain skills that you can entrust to take away the burden and give you peace of mind that your environment is being taken care of. For assistance with PostgreSQL databases, or simply just some independent advice to point you in the right direction, feel free to chat to one of our experts.