I am thinking of migrating MariaDB 10.3.13 to RDS, I want to do an analysis of what limitation can be caused by migrating to RDS, I could find no documentation by AWS for MariaDB for issues and imitations, however there is a MySQL doc for issues and limitations, I am wondering do the same limitations apply to MariaDB?

  • do the same limitations apply to MariaDB? Not all MariaDB limitations are inherited from MySQL, some of them were altered during the fork. And from this forking point the limitations history is independent. Taking into account that this was far ago (relatively, of course) the generic answer seems to be "unknown/unpredictable". And AWS may add its own limitations, both common and specific to MariaDB. – Akina Mar 11 at 9:27
  • In addition to what Akina said, because AWS likely has additional limitations as well, your best bet is to talk to an AWS Solutions Architect or your AWS Rep to clarify all limitations. – J.D. Mar 11 at 12:39
  • I recommend to test every feature yourself if you're in doubt. I've gotten bad advice sometimes from AWS Solution Architects. Most are correct, but you can't know which ones. They are especially reluctant to tell you about limitations of their product. It's like they are all salespeople, and they try to hide any limitations or weaknesses. You have to double-check everything they seem to tell you, or else you'll be unpleasantly surprised. – Bill Karwin Mar 11 at 23:00

Short answer: Probably yes.

Long answer:

I reviewed that link. All three (MySQL, MariaDB, RDS) are derived from the same original code. As far as I know, all three have, or at least had all of those bugs/issues/etc. When one of the 3 fixes a bug, the others may eventually pick up the fix.

For innodb_buffer_pool_instances, MariaDB seems to be leading the change: MariaDB-10.5.1 changelog says that innodb_buffer_pool_instances deprecated.

WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2' -- This is almost certainly fixed by using a composite index rather than depending on index merge.

The 10x for blobs was a workaround that was mentioned in 5.6(?). It may be relaxed in some later version.

lower_case_table_names is a kludge to porting to both Windows and Unix. It got worse with 8.0's Data Dictionary. So, beware of switching OS's

As for the 16TB limit for an InnoDB table, I thought it was 32TB or 64TB. It won't be long before someone finds out for sure.

Lower limits such as 2 TB, and long ago, 2 GB are probably dictated by the underlying Filesystem on the Operating System.

long_query_time allowed microseconds long ago, in 5.1.21, before MariaDB forked off. I don't understand why AWS mentions it.

My list of limits: http://mysql.rjweb.org/doc.php/limits

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.