Postgresql – Database extensions vs migrations

database-designmigrationpostgresql

When using of database specific features (instead of 3rd party solutions) is justified, especially on the beginning stage of the project?

Example: Postgres has full-text search, which do not support some features of search engines (i.e. facets) but is pretty acceptable for my needs. It requires postgres-specific extensions. But if I use postgres extensions instead of ElasticSearch, I'll bind myself to postgres. Is that a bad practice?

Am I right if I say that all new projects should start with RDBMs (due query flexibility, data normalization) and than migrate to i.e. NoSQL if needed?
If yes, than using db-specific features interfere db migrations in future, and is a bad practice. Also extensions can break db migration tools like Flyway.

Best Answer

If you migrate from RDBMS to NoSQL then you will also have problems. They are not interchangeable for all types of usage.

When you start a project then just before you start the creation of your data objects you must choose the one that suits best to your needs. Changing later will nearly always cause problems as soon as you use more then the 'standard' options.

When you choose to use a third-party extension then there is always the risk that:

  • Support/development of the extension stops. When you upgrade your database then the extension might no longer work;
  • Another better third-party solution is created. When you want to use it then you face incompatibility problems with the current third-party extension;
  • The third-party extension gets integrated in the database that you use.

The last option is the best one.