PgConf.Russia 2020

Role-based access control (RBAC) is one of the main mechanisms used for access control in many DBMS, including PostgreSQL. This model is a sub-type of traditional discretionary access control with its restrictions. In addition to DAC, many operating systems also use mandatory access control (MAC) based on security labels. This additional security mechanism is obligatory for protecting information that demands higher levels of security. Naturally, we would like to use MAC within DBMS when working in OS with mandatory access control switched on.
In this talk, we'll give an overview of existing MAC implementations in DBMS, as well as share our approach to using security mechanisms provided by SELinux, the sepgsql extension for PostgreSQL, and the standard mechanism of row-level security (RLS), which has been available in PostgreSQL starting from version 9.5.
In our presentation, we will use the "Airlines" demo database provided by the Postgres Professional company to show how to protect sensitive information and personal data, compare different ways of storing security labels, and assess performance of our solution.

An enterprise-grade PostgreSQL requires many complementary technologies to the database core: high availability and automated failover, monitoring and alerting, centralized logging, connection pooling, etc. That is, a stack of components around PostgreSQL. Kubernetes has enabled a new model to deploy software abstracting away the infrastructure. However, containers are not lightweight VMs, and the packing of software paradigms that work on VMs are not valid on containers/Kubernetes. How should be PostgreSQL and its stack be deployed on Kubernetes? Enter StackGres. An open source software that is the result of re-engineering PostgreSQL to become cloud native. Join this talk to learn and see demos of how to generate PostgreSQL minimal containers; how the sidecar pattern is used (abused) to integrate PostgreSQL’s stack components, and how the networking and storage are handled. More info: stackgres.io.

Many businesses which use Database management systems like Oracle, DB2 & MS SQL are unreliable these days. Moreover, the costs incurred in maintaining these systems and its product licenses keeps on increasing. As the competitors are migrating over to the new technologies and tools available in the market, it is necessary for these businesses to migrate to new environment which is efficient, consistent and reliable to stay in the market and the technologies used in the current environment have become obsolete or no longer serve the business purpose. PostgreSQL has emerged as a top open-source RDBMS software. Since there is no licensing cost associated with it most of the companies are planning to migrate the databases which are currently running on other RDBMS like Oracle, DB2, MS SQL server to PostgreSQL. This report summarizes the various methodologies, procedures and techniques involved in successfully migrating the data from Oracle to PostgreSQL & DB2 to PostgreSQL. Migration is not a simple effort there should be proper planning and testing involved in this right from database connectivity to performance analysis. In this paper we are going to cover most of the steps which we need to consider before the migration and after the migration like choosing the correct tools for implementing the migration, time taken to migrate ,data compatibility, code conversion, application connectivity to database, database configuration parameters, performance analysis, replication setups, database monitoring, patching and backup strategies.

Patroni and Stolon are two of the most popular and advanced solutions for orchestrating PostgreSQL and ensuring auto-failover for clusters with the Leader-Followers configuration. However, engineers who migrate from good old tools like Corosync&Pacemaker or built-in solutions of other DBMS often run into issues when installing these tools and figuring out the purpose of each component.
In this tutorial, we will go through a typical installation procedure of Patroni and Stolon clusters on virtual machines (not in containers), as well as review their behavior in case of various infrastructure failures. The whole process will be demonstrated on three vagrant virtual machines with pre-built images. You can follow along on your own system if you set up the required environment.