PgConf.Russia 2020

A brief story how MySQL → PG migration could increase company efficiency tenfold times:

1. Program code has been reduced 50 times, with optimization of backend team (from 15 to 3 engineers)
2. Software development of new features has become measuring in days, not in months
3. Infrastructure costs per 1M users have been reduced 20 times
4. Database structure and technical documentation were simplified significantly, from 100K high-dependent tables to just 20 simple tables
5. New security level because of total forbidden on external SQL commands to the database
6. Quick analytics aggregation on multiple parameters, without external analytics systems
7. The last, but not the least: the main business was keeping alive during migration

I will speak about our experience in solving the fault-tolerance problem for PostgreSQL, which options we reviewed and how we chose Patroni.

I will cover solution testing, quick implementation to the production and issues we faced as well as the way we solved them.

When migrating data from one DBMS to another, the question arises: choose a third-party tool or to program the migration yourself? Companies, trying to grow competencies within themselves, choose the second option. And they come across the "invention of their own bicycles". However, the market has powerful free data migration tools. One such tool is Pentaho Data Integration, part of the Pentaho Community Edition. The report will discuss the use of this package for data migration between Oracle and PostgreSQL. Particular attention will be paid to the problems with using this tool, and to the tasks of testing for the completeness and integrity of migrated data.

Small video illustration:

Recently, I was working on a project where graphQL was used for sending requests to its .NET Core backend, but this was not a good idea. The point is, a graphQL query is a hierarchical structure with a dynamic set of fields. It’s difficult to perform such requests via a statically-typed programming language and a relational database as suggested by the tools available. So, I came up with the idea of using the plv8 extension and perform graphQL queries right on the database side. It took me about two hours to develop a working prototype that could perform the same queries as the software under development for more than one month! Then various improvements have been made and I want to introduce them all. If you are thinking of using graphQL instead of REST, my speech could be most useful and could help you to save a lot of time.