What database supports over a thousand fields and tables

Barry Morris here from NuoDB. Answers below:

1) DBaaS (can be self hosted too) the can easily scale to terabytes of data (ie. big data)

• NuoDB is a downloadable product that runs anywhere (laptop, rack, public cloud). We have not announced DBAAS at this point. NuoDB uses Key/Value stores at the storage layer so supported DB sizes will be related to whatever the particular KV store can handle.

2) Capable of very high throughput for real-time application that does many read/writes (although I will use caching too to reduce overload)

• NuoDB is a general purpose database system designed for high-speed scaled-out transaction processing. There is no need for a separate cache tier because the NuoDB in-memory tier performs a similar function.

3) Being able to query the data using SQL, a RDBMS DB. Although if a NewSQL solution isn't available, I will go with NoSQL

• Check. NuoDB is a SQL database.

4) Easy backup and restore big amount of data in case of data corruption. I know that many solutions are safe against server failure, but I worry about data corruption and I want to be able to restore the data back if that happens - IMPORTANT!

• NuoDB supports JDBC, ODBC and other standards APIs, so backups can be done at the SQL level. Other alternatives include simply taking one of your storage managers offline and putting it somewhere safe.

5) I will be developing my web app / mobile app in ASP.NET, so I prefer a solution that have a .NET connector

• NuoDB has an ODBC API and there is a community developed ASP.NET connector.

6) If hosted, I prefer hosting my DB on Amazon AWs.

• NuoDB supports Amazon AWS

7) I don't want a self-managed solution and handle sharding and all the other complicated stuff

• No sharding or partitioning (or caching, M/S replication etc) needed with NuoDB.

8) I want an affordable solution, not like Clustrix that costs thousands of dollars per node. I want a cost-effective solution where I can start small and pay more when my database grows (all idea behind cloud architecture, right?)

• NuoDB is free forever for a baseline system.

You could store the text file data in a table like this:

config_files
------------
  ID (PK)
  name
  parent_dir_id (FK to config_dirs.id) 
  content

config_dirs
-----------
  ID (PK)
  name
  original_user (key to the table that stores the original user data)
  parent_dir_id (key to config_dirs.ID, needs to be nullable to indicate a root directory)

Populating this structure, you could do something like this:

config_dirs
-----------
ID    | name       | parent_dir_id | original_user
------+------------+---------------+--------------
1     | conf       | (null)        | Toby Derius
2     | users      | 1             | Toby Derius
3     | admin      | 2             | Toby Derius
4     | bob        | 2             | Toby Derius

config_files
------------
ID    | name       | parent_dir_id   | content
------+------------+-----------------+--------
1     |general.cfg | 1               | This is the general config...
2     |admin.cfg   | 3               | admin's config...

This could allow you to query the directory structure and the file contents for specific users. Storing large amounts of plain text is not always a great idea, in terms of performance, so you might also want to consider storing the contents in a separate table file_contents and then referencing the file_contents from config_files. Also look into fill-text search engines.