Why purchase a prebuilt database when you could develop your own?
There are many problems that can arise when you develop your own database storage engine. At first, it may seem simple to just store the information you need in a flat file and let it grow as you develop and use your application. Unfortunately, feature creep can easily cause complications to this design. Let's say that your application has been released and is currently being utilized by your customers. One common new requirement is now a need to use that same data store in the file for Business Intelligence purposes but there is no ability for this file to be loaded into any commercially available BI tools like Microsoft Excel, SAP Business Intelligence, Tableau, and others. In order to facilitate this, you need to now develop a way for these tools to connect to your internally developed system. You could contact that BI application developer and work with them to implement your database in their tool or you could spend time developing an industry standard connection interface like ODBC, JDBC or ADO.NET. Both of these options will require time and monetary investment, easily ballooning your initial costs and reducing or removing your cost savings by not using a commercial database like RDM.
Another common problem occurs when there may be a need for the data to be available in multiple places at once for redundancy or throughput purposes. Creating a robust replication or mirroring solution to this problem is incredibly time-consuming to both develop and test. There are many issues that can arise such as how to transport the data, what happens when the connection goes down, how do you allow for flexibility in what data is actually replicated/mirrored, and so on. A packaged product will have already done this work and guarantees these features, stability and configuration options.