I hate to interrupt and go against the flow here, but it seems that some main points have not been mentioned.

First, the OP is talking about his 'business', no doubt a software and Web site based business, but still a business.

Here is the history of database for businesses in four easy steps:

Step 1.

In the 1950s with computers and then and before for a few decades, people did business computing with, say, files and decks of punched cards.

Step 2.

In the 1960s it was noticed that a small change in the business could result in too much programming; so the idea of 'database' was born. There for new purposes could add fields, links, etc. to the database without need to revise old software -- a huge point.

Approaches in the 1960s included hierarchical and network.

Step 3.

In the 1970s the mature conclusion from the experience of the 1960s was that a 'database' should be 'relational' with tables and relations. Each table had one column for each quantity and one row for each instance of those quantities. E.g., maybe in one table there was one row for each customer and one column for each quantity about a customer -- customer number, phone number, billing address, etc. A table usually had a key, and the table was in 'third normal form' so that each row was a function of the key, the whole key, and nothing but the key. Tables with relatively few columns could be combined, as needed for ad hoc purposes, into new, possibly larger, tables with 'join' operations based on 'relations'.

Leaders in this movement included E. Wong at Berkeley and M. Blasgen at IBM's Yorktown Heights lab. The Wong work resulted in INGRES, and the Blasgen work resulted in R* and later DB/2.

As database theory, the story was in good shape as of 1980. See, e.g.,

Jeffrey D. Ullman, 'Principles of Database Systems, Second Edition', ISBN 0-914894-36-6, Computer Science Press, Rockville, MD, 1982.

A relational database is usually programmed in 'structured query language' (SQL), and it is standard. SQL is easy to learn and fun to use.

Relational database systems take data integrity and security, system reliability, and data backup and recovery very seriously. A key to the functionality is the 'log file', and one result is the ability to backup a database while it is executing reads, writes (inserts, updates, deletes). If there is a hardware failure, say, power outage, in the middle of a large operation, then when the power comes back on the database will be put back in a 'consistent' state. There are extensions for parallelism, redundancy, and distributed implementation. The algorithms are advanced, and the software is mature and very thoroughly tested. E.g., a complicated operation is carefully 'complied' into a 'plan', and that with smart use of caching data in main memory commonly results in shockingly good performance. If a complicated operation is needed, then it will be difficult to beat the performance of just stating what is desired in SQL and letting the database software do the rest. There are mature tests of performance; see, the Transaction Processing Performance Council work at

http://www.tpc.org/

The performance achieved on the tests, from simple to very complicated, is astoundingly high.

For a business, relational database brings high 'flexibility': With well designed tables, relational puts the business in the best position to meet the data manipulation needs a few years in the future where the needs are not understood now. This one point is likely the most important reason for a business to take relational database seriously.

Well known relational database systems now include SQL Server, Oracle, DB/2, MySQL, and some more.

Curiously, conceptually the files in the punched card days were much like relational database now. So, one deck of cards corresponded to one database table. All the decks together corresponded to the whole database. In one deck, each card corresponded to a database row, and each field on the card corresponded to a database column. It was common to sort a deck on a column. Given two decks sorted on a common column, it was common to 'collate' the two decks and create a third, and that operation is essentially a relational database 'join'.

Broadly, the basic operations needed to do well manipulating database data have been known for nearly 100 years.

Step 4.

As the Internet and Web servers grew in importance, there have been needs for special purpose database systems with, compared with relational database, more performance but less functionality and generality. So, we have NoSQL, key/value stores, etc.

Most experienced programmers know some SQL, and even if they do not it should be easy for them to learn and start having fun with SQL quickly. A program in SQL is just simple text and is easy to type, comment, and read. For the fun, J. Bezos at Amazon had fun early on when he saw how easy it was to get some really nice information about Amazon's business from a simple query typed in as SQL.

For using relational database in a startup, the main management issue will be the need for the expertise of a 'database administrator' (DBA). For a startup, first, hopefully it's reasonable just to f'get about a DBA, keep everything simple, and do the work in-house. For background, read the chapter on database in, say,

Jim Buyens, 'Web Database Development, Step by Step: .NET Edition', ISBN 0-7356-1637-X, Microsoft Press, Redmond, Washington, 2002.

and then read the first chapter of Ullman above.

Second, as the work gets more challenging, get a good phone number, call, and ask questions of some person who does DBA work full-time. Paying a high hourly rate to such a person will still be much cheaper than having a good DBA in-house. E.g., for working through some tricky issue in security or performance monitoring will be much easier if call someone who considers such things full-time. If get to be a big company, then, sure, have lots of in-house database expertise.

So, net, for the BUSINESS, use relational database. For some special purposes in, say, high performance Web site architecture, maybe start by just using relational database but when more performance gets to be crucial move to special purpose tools.

Really, the special purpose tools are not directly competitive with relational database. E.g., at my Web site, I'm keeping all the important data in relational database. But in one case, for one special purpose, some data in the relational database is read into some simple files and used read-only with very high performance, maybe off SSD or just in virtual memory. In another case, I'm implementing a simple key/value store, a baby Redis, so simple it is easier for me to program what I want than even to read the Redis documentation. What I am programming can knock the socks off relational database in several respects and do well for my company until it is so big I can let others worry about what else to do. But, for my BUSINESS, including all the important data in my Web server farm, that's in relational database. Period.