.
Webcast There was a time when open source was still– no matter how many years it had actually driven software application projects– considered the play ground of hippies and utopians. Bold and brave, yet thrown up, irregular and unsecured when compared to more established products.
As incumbent vendors saw sense and bolted open source offerings onto their item load-outs, or even obtained well known open source gathering spots outright, open source all of a sudden became cool. Typical, even.
For relational databases, and the systems that managed them, this was a smile and nod moment. As early pioneers of open source, there are feature-packed, hugely portable and acutely established options offered for anyone wanting to leave a big old supplier, enormous yearly costs, and cunningly-constructed vendor lock-in.
All of this can come from anybody– and it’s available right now. There’s just one catch: Some of those general understandings around open source remain. While it’s increasingly accepted that “throwing up” code from diverse sources is great, and sometimes even great, in order to innovate with dexterity, making an open-source RDBMS completely protect can still be a sticking point. From those establishing the job to senior management and board directors, everybody’s going to have one eye on a possible security catastrophe.
This is what we’ll be considering in an approaching webcast. Taking the age-old PostgreSQL as our open-source RDBMS of choice, we’ll be thinking abou
Learn More