Experience: 3 years

I have an experience with both traditional relational databases and NoSQL.


I worked with PostgresSQL, MySQL and SQLite. PostgreSQL is a universal option that has some useful features like triggers and can even store JSON. Nevertheless, MySQL was the database of choice in 00s, so I had a chance to work with it as well (including MariaDB). I also used SQLite to collect and store operating information of the testing devices I developed.

Despite the potential of SQL as a DSL, there has not been a need to optimize database queries in my practice yet, in contrast to the abundance of many-to-many relationships in relational schemas. For this reason, my experience is primarily based on interacting with an ORM.


Among the document-oriented databases, I have the most experience with MongoDB , to a lesser extent with CouchDB and ArangoDB . The idea of storing documents as a whole is not a bad idea until there is a need to make batch requests for separate fields of documents in different collections. Even a specialized query DSL (ArangoDB) or REST-based queries (CouchDB) are not up to the performance and convenience of SQL, so now I have a rather reserved attitude for databases of this type.

Among key-value storages, I used Redis to store process IDs in the task scheduler and used it as a primitive message queue. It worked well, but at some point RabbitMQ was deployed for MQ purposes.

Among columnar databases, I have a little experience with HBase which I planned to use for an analytics task, but then it became clear that a columnar database was not suitable for that particular task, and I didn’t return to it anymore.


email icon telegram icon github icon