You need to use the product you know better or, failing that, the one with the best support in the community. Other topics to keep in mind in parallel are what you want to use it for; There are databases that have some characteristics that make them better or worse for certain tasks. But basically it is best that you always use the product that best suits what you need, regardless of the type of license (whenever you can, of course).
Security, performance and scalability is what i will go for, security of the data stored is very crucial to any organisation and how fast can the data be accessed/retrived and finally how well is the database engine handling growing volumes of data
The selection aspects are the same as the others are already mentioned.
Here is a live case:
In my opinion postgreSQL is the right database for even enterprise class applications. It is know everything that the commercial knows: stored procedures/functions / views / constraint checking etc. It has a relative small footprint of memory and disk space. The command line console & the GUI is also quite good. Easy to install, and it is not need too much maintenance effort. Extremely configurable,it has database connector to Java / C#(?) etc. We use it for a 11 liferay instances and all in all 1800 microsite maintenance.
Evaluation of open database must be simple to use, graphical user interface is a plus. Then if you have a huge amount of data, scalability and performance to flesh the data is also important. Secure database is one of most important aspect in database, because is where critical data are there. An other aspect of monitoring, replication and backup is also important. After depending of your choice SQL database or non SQL, that is related to your application. Let see if you have a well structured datas like ERP system for a example, then scalability and security are the most criteria to choose the right opensource database. However if the size of the database table is increasing exponential, more than 32 terabyte. then a vendor solution may be more suitable like ORACLE or less expansive Aurora from AWS.
With open source databases, I think you first have to consider your present requirements with regard to security, evolution over time, usability, reliability. You should also think of new requirements that might come in the future. it might be wise to select a database solution that has as enough flexibility y to meet the new challenges of your organisation.
The security primarily, the scalability, the usability and the processing capacity before complicated query, verify the base code of the same and determine which is the method used to carry out the query
Before jump into an Open Source Database, you need to understand that any bug or feature is attached to the workforce behind it. It could be a company/companies or a huge community. Been said, you need to practice patience and learn how to feed the cycle to improve it too. You can be a passive user, it's ok, but part of the joy is to collaborate back to the community. You can do it in many ways.
Inside the Open Source Database ecosystem you will find almost a fit for every need, but certain features (specially those in state of art) are mostly available on privative databases. So, sometimes you will need to get into some imagination and artisan mechanisms to make them work as you need, for very specific purposes. Nowadays, this gray area is shrinking but there are certain areas wether OSD do not fit well or lack of some very advanced features.
And the most important part: do not _only_ read the documentation, improve it if you can!
While Accessing the Open source Database, below information should considered.
1. With any mission critical database, max. recovery should be possible which open source can not gave guarantee
2. From security, and performance prospective no one has accountability to fix the issue. During the catastrophic failure, relying on open source database could prove a big mistake for the organization. Loss of time/Manpower and Loss of business.
3. Open database creates more challenges during day to day support and maintenance of the application and relying on open database technology used may delayed or postpone the business development schedule.
So in long term, It could prove to be costly and a major business failure. You will not find any mission critical database relying on Open Source database technology (e.g. Banking,Capital market stock securities and so on)
Firstly check if it is ANSI SQL compliant so that we can get standard SQL developers from resourcing perspective. Next if it is intended for production and time critical application then timely support for any issues is very important. If there are companies who provide professional support services for this database then that's the best. Check if replication and/or backup & restore capabilities are good to handle High Availability and Disaster Recovery.
Another important point is does this solution fit for the kind of problem we are trying to solve - like are we trying to build a web portal solution and need split second responses or solving bulk data load problem etc.
Also look for data security features like role based object permissions etc.
While evaluating Open-Source Products, the main concern is limitations to that product as well as support provided either official and community. Secondly using Open Source on Production environment is always risky unless all risk variables are known. So complete knowledge of that open source product especially limitations
if databases are involved, scalability is always my initial concern, then performance(metrics), then finally, but not least, the efficiency and performance of the agent/medium between it and the application that will use the database.
I think it entirely depends on the use case. If you're looking to dig a hole, you want to evaluate shovels, not all yard tools. If my project is focused on delivering high-scale, real-time analytics, then metrics around latency, replication times, and performance are important. If I'm looking to build a large, web-based application, I would likely evaluate security, ease of scaling out/sharding, and APIs. Choose the right solution for the problems you're trying to solve. Your time should be spent on creating value and functionality, not working with flashy features of the supporting platform.