PgConf.Russia 2016

The Korean PostgreSQL User Group has been relatively small and inactive for many years. However, recently things are changing in Korea. Companies are seeking to alternatives for their expensive proprietary RDBMS in order to cut their TCO. And the government institutes also participate in this trend. We, Bitnine, are leading these changes in Korea. We launched the first version of our PostgreSQL solution, Agens SQL in 2015. We are translating the PostgreSQL documentation into Korean and operating the PostgreSQL User Group. And we are trying to contribute the PostgreSQL Global Development Group. Also, the first Korean PostgreSQL Conference will be hold in 2016. We will lead the organization of this conference. In this talk, we will present the current status of the Korean PostgreSQL User Group and the PostgreSQL DBMS market in Korea. And we also present our activities in Korea and introduce our successful migration cases of the proprietary RDBMS into PostgreSQL.

A backup is something that no Postgres deployments should go without as it gives the insurance to get back a deployment on its feet should a disaster strike.

In this talk we will discuss why backups are essential in any sane PostgreSQL deployments (this seems obvious) and what are the different options available to define and set up a good backup strategy. On top of that is discussed how the future of backups would need to be handled, particularly regarding differential backups that gain in popularity among users with large deployments.

Since its launch in 2008, Zalando has grown with tremendous speed. The road from startup to multinational corporation has been full of challenges, especially for Zalando's technology team. Distributed across Berlin, Helsinki, Dublin and Dortmund — and nearly 900 professionals strong — Zalando Technology still plans to expand by adding 1,000 more developers through the end of 2016. This rapid growth has showed us that we need to be very flexible about developing processes and organizational structures, so we can scale and experiment. In March 2015, our team adopted Radical Agility: a tech management strategy that emphasizes Autonomy, Purpose, and Mastery, with trust as the glue holding it all together. To make autonomy possible, teams can now choose their own technology stacks for the products they own. Microservices, speaking with each other using RESTful APIs, promise to minimize the costs of integration between autonomous teams. Isolated AWS accounts, run on top of our own open-source Platform as a Service (called STUPS.io), give each autonomous team enough hardware to experiment and introduce new features without breaking our entire system.

One small issue with having microservices isolated in their individual AWS accounts: Our teams keep local data for themselves. In this environment, building an ETL process for data analyses, or integrating data from different services, becomes quite challenging. PostgreSQL's new logical replication features, however, now make it possible to stream all the data changes from the isolated databases to the data integration system so that it can collect this data, represent it in different forms, and prepare it for analysis.

In this talk, I will discuss Zalando's open-source data collection prototype, which uses PostgreSQL's logical replication streaming capabilities to collect data from various PostgreSQL databases and recreate it for different formats and systems (Data Lake, Operational Data Store, KPI calculation systems, automatic process monitoring). The audience will come away with new ideas for how to use Postgres streaming replication in a microservices environment.

Postgresql's buffer manager has parts where it's showing its age. We'll discuss how it currently works, what problems there are, and what attempts are in progress to rectify its weaknesses.

• Lookups in the buffer cache are expensive
• The buffer mapping table is organized as a hash table, which makes efficient implementations of prefetching, write coalescing, dropping of cache contents hard
• Relation extension scales badly
• Cache replacement is inefficient
• Cache replacement replaces the wrong buffers