PGConf.Russia 2018

If you honestly evaluate most of our business applications, you will see that they first collect and import the data into a database and then send the same data in the opposite direction.

What if we don't build an ORM wall between the application and the database, but try using the symbiosis of their strong points and special features instead?

I will tell you how we use PostgreSQL and Clojure for building data-intensive medical applications. We will cover the following topics:

• functional relational programming
• jsonb for modeling complex data domains
• functional indexes and json-knife extension for jsonb search
• graphql implementation on PostgreSQL
• logical replication for building reactive integrations
• asynchronous JDBC-free connector to PostgreSQL on netty

I would like to share experience in runing PostgreSQL in dockerized environments, describe the specific issues and tools you will need to solve them.

• Which problems could be solved by Docker for PostgreSQL, e.g. PostgreSQLPro.9.6
• Work of IT team with Docker in development, testing and production environments
  • Using image repository and build servers for image testing
• Issues in production environment:
  • With network activity
  • With persistent repositories for Docker
  • With additional services
  • With load balancing and fail-safety
• Running PostgreSQL-base applications, such as:
  • SonarQube
  • Gitlab
  • 1С platform

When one faces the issues with PostgreSQL, the main suspicion falls on vacuum. Experience of Data Egret team proves how many DBAs are attacking this rake. While there are tons of information, documentation and discussions on vacuum itself, the topic is still associated with a lot of myths, tales, horror stories and misconceptions. In my talk I will try to reveal the key points concerning the inner structure of vacuum, basic approaches to its adjustment and tuning, performance monitoring, and so on.

Comparison of capabilities of PostgreSQL and MS SQL to work with 1С. What does pg_restore mean for 1С user? Results of load testing for 1C database of more than 1TB size. The story of one 1C Production: 2 years, 500+ databases 1C, 4TB of data, cascading replication.