PgConf.Russia 2020

In the report, we want to talk about the experience of migrating one large system from Oracle to PostgreSQL. The system itself was built on the PHP + Oracle stack; its distinguishing feature was that all business logic was implemented in PL / SQL code. In a DBMS, there are more than 3000 packages with 4-10 functions (procedures) in each. In PHP - more than 10,000 forms with inserts of anonymous blocks used to receive data, process and save results in Oracle.

To solve this extremely voluminous work, we took ANTLR4 (a powerful parser generator for reading, processing, executing, or translating structured text), PL/SQL grammar, and created an automatic converter that allows you to convert all objects in the schema and our system from Oracle to working code for PostgreSQL.

Moscow public transport vehicles when moving report their coordinates via GLONASS. Collected data is used for various analyses including timetable development, bottlenecks detection and planning the bus lanes. Until recently we used the PostGIS extension for this purpose but now we are switching to a new PG extension — MobilityDB — designed especially for geodata time series processing. I have compared the table size and the performance of our solution without and with MobilityDB and happy to present the results.

Today no one is surprised by cloud infrastructure anymore, but not all its components are easy to deploy in cloud. For example, the database is always very demanding in terms of performance and resources. Scaling and fault tolerance are the most acute problems, that's why we have been observing rapid development of alternative DBMS in the recent years. However, traditional relational DBMS have already accumulated a lot of various features, so they often remain the first choice. Besides, they are constantly evolving and offer a wide variety of scaling tools. I will mainly speak about PostgreSQL, when you should consider scaling, and how to do it right.

We will touch upon the following topics:
- Streaming replication and balancing read/write workloads
- Logical replication and data sharding
- High availability and fault tolerance

This talk should be interesting to DBAs, system administrators, team leads, infrastructure architects, as well as wider audience dealing with PostgreSQL.

We will discuss stored procedures and functions, as well as the code within the database in general. We'll take a look at stored procedures from different angles: as a DBA, a database developer, and a backend developer. We will try to understand the specifics of stored procedures that often go against the common coding guidelines, and discuss best practices for working with stored procedures.
This is mainly a motivational talk for database and backend developers, not an advanced tech talk.