What data quantity is considered as too big for MySQL?

Question

I am looking for a free SQL database able to handle my data model. The project is a production database working in a local network not connected to the internet without any replication. The number of application connected at the same times would be less than 10.

The data volume forecast for the next 5 years are:

• 3 tables of 100 millions rows
• 2 tables of 500 millions rows
• 20 tables with less than 10k rows

My first idea was to use MySQL, but I have found around the web several articles saying that MySQL is not designed for big database. But, what is the meaning of big in this case?

Is there someone to tell me if MySQL is able to handle my data model? I read that Postgres would be a good alternative, but require a lot of hours for tuning to be efficient with big tables.

I don't think so that my project would use NOSQL database. I would know if someone has some experience to share with regarding MySQL.

UPDATE

The database will be accessed by C# software (max 10 at the same times) and web application (2-3 at the same times),

It is important to mention that only few update will be done on the big tables, only insert query. Delete statements will be only done few times on the 20 small tables.

The big tables are very often used for select statement, but the most often in the way to know if an entry exists, not to return grouped and ordered batch of data.

Answer 1

I work for Percona, a company that provides consulting and other services for MySQL solutions.

For what it's worth, we have worked with many customers who are successful using MySQL with very large databases. Terrabytes of data, tens of thousands of tables, tables with billions of rows, transaction load of tens of thousands of requests per second. You may get some more insight by reading some of our customer case studies.

You describe the number of tables and the number of rows, but nothing about how you will query these tables. Certainly one could query a table of only a few hundred rows in a way that would not scale well. But this can be said of any database, not just MySQL.

Likewise, one could query a table that is terrabytes in size in an efficient way. It all depends on how you need to query it.

You also have to set specific goals for performance. If you want queries to run in milliseconds, that's challenging but doable with high-end hardware. If it's adequate for your queries to run in a couple of seconds, you can be a lot more relaxed about the scalability.

The point is that MySQL is not a constraining factor in these cases, any more than any other choice of database is a constraining factor.

---

Re your comments.

MySQL has referential integrity checks in its default storage engine, InnoDB. The claim that "MySQL has no integrity checks" is a myth often repeated over the years.

I think you need to stop reading superficial or outdated articles about MySQL, and read some more complete and current documentation.

• MySQLPerformanceBlog.com
• High Performance MySQL, 3rd edition
• MySQL 5.6 manual

Answer 2

MySQL has a two important (and significantly different) database engines - MyISAM and InnoDB. A limits depends on usage - MyISAM is nontransactional - there is relative fast import, but it is too simple (without own memory cache) and JOINs on tables higher than 100MB can be slow (due too simple MySQL planner - hash joins is supported from 5.6). InnoDB is transactional and is very fast on operations based on primary key - but import is slower.

Current versions of MySQL has not good planner as Postgres has (there is progress) - so complex queries are usually much better on PostgreSQL - and really simple queries are better on MySQL.

Complexity of PostgreSQL configuration is myth. It is much more simple than MySQL InnoDB configuration - you have to set only five parameters: max_connection, shared_buffers, work_mem, maintenance_work_mem and effective_cache_size. Almost all is related to available memory for Postgres on server. Usually work for 5 minutes. On my experience a databases to 100GB is usually without any problems on Postgres (probably on MySQL too). There are two important factors - how speed you expect and how much memory and how fast IO you have.

With large databases you have to have a experience and knowledges for any database technology. All is fast when you are in memory, and when ratio database size/memory is higher, then much more work you have to do to get good results.