Amazon RDS for MariaDB 12.3 Is Now Generally Available (GA), So I Tried It Out

Amazon RDS for MariaDB 12.3 Is Now Generally Available (GA), So I Tried It Out

MariaDB 12.3 is an LTS release. On Amazon RDS, I compared a new 12.3.2 instance with one upgraded in place from 11.8.8, checking reserved-word impact on existing SQL and differences in parameter group values.
2026.08.13

This page has been translated by machine translation. View original

Introduction

On August 11, 2026, AWS What's New announced Amazon RDS for MariaDB 12.3.2.

https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-rds-mariadb-1232-available/

I'll check the release dates and end-of-support timing for each major version of RDS for MariaDB, using the MariaDB version management documentation.

MariaDB major version Community release date RDS release date Community EOL RDS standard support end
12.3 May 28, 2026 August 7, 2026 June 2029 June 2029
11.8 August 6, 2025 August 25, 2025 June 2028 June 2028
11.4 August 8, 2024 October 15, 2024 May 2029 May 2029
10.11 February 16, 2023 August 21, 2023 February 16, 2028 February 2028
10.6 July 6, 2021 February 3, 2022 July 6, 2026 November 2026
10.5 June 24, 2020 January 21, 2021 June 24, 2025 August 2026

10.5 and earlier are listed as deprecated versions in the same documentation.

At the patch version level, Supported MariaDB minor versions on Amazon RDS in the same documentation lists the RDS standard support end for 12.3.2 as August 2027.

During the preview period it was available only at rds-preview.us-east-2.amazonaws.com, but after GA it is available in the regular Regions. describe-orderable-db-instance-options returned 12.3.2 as an engine version selectable when creating a DB instance in the Tokyo Region (ap-northeast-1) as well.

The testing in the preview environment is summarized in the earlier article below.

https://dev.classmethod.jp/articles/rds-preview-mariadb-12-3-new-features/

In this article, for a newly created 12.3.2 instance and for an instance upgraded in place from 11.8.8 to 12.3.2, I'll check how column name notation and parameter group setting values change.

Notes When Upgrading to 12.3

Notes for upgrading from 11.8 to 12.3 are listed in the official MariaDB and AWS documentation.

  • Reserved words were added, and they can no longer be used as identifiers without quotation marks. The ones I confirmed to have an impact in this article are TO_DATE and CONVERSION (Upgrading from MariaDB 11.8 to MariaDB 12.3)
  • The default value of innodb_snapshot_isolation is now ON. Applications that depend on the transaction isolation level need to be tested (MariaDB Foundation announcement)
  • big_tables / storage_engine / large_page_size were removed (the upgrade guide above)
  • On replicas, the master_use_gtid setting is not carried over and is reset to DEFAULT. This is fixed in 12.3.3 (same guide)
  • A major upgrade cannot be rolled back to the previous version after it completes. The documentation recommends taking a snapshot beforehand and trying the upgrade first on an instance restored from the snapshot (AWS documentation)

Below, I show the results of actually testing the reserved words and the changes in values that can be set in parameter groups.

Testing

Test Environment

The testing was done in us-west-2 using two db.t4g.micro DB instances. One was newly created with 12.3.2, and the other was created with 11.8.8 and then upgraded in place to 12.3.2. I connected from EC2 via Systems Manager Run Command, using a TLS connection with the RDS CA bundle.

Checking Reserved Words

I checked the engine version on the newly created instance.

SELECT VERSION(), @@version_comment;
-- 12.3.2-MariaDB | managed by https://aws.amazon.com/rds/

CREATE TABLE statements that specified to_date and conversion as column names without quotation marks both resulted in syntax errors.

CREATE TABLE gatest.t_to_date (id INT PRIMARY KEY, to_date DATE)
ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'to_date DATE)' at line 1
CREATE TABLE gatest.t_conversion (id INT PRIMARY KEY, conversion VARCHAR(16))
ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'conversion VARCHAR(16))' at line 1

When enclosed in backticks, tables could be created with the same column names.

TO_DATE remained usable as a function.

SELECT TO_DATE('2026-08-12', 'YYYY-MM-DD');
-- 2026-08-12 00:00:00

Upgrade Path

Because RDS does not offer 12.0 / 12.1 / 12.2, the next major version after 11.8 is 12.3. Looking at ValidUpgradeTarget in describe-db-engine-versions, 12.3.2 was returned from each of 11.8.8 / 11.4.12 / 10.11.18, confirming that they are eligible for in-place upgrade.

Major version upgrades for RDS for MariaDB also lists Any MariaDB version to MariaDB 12.3 as a supported path.

Upgrade Preparation and Execution

On 11.8.8, I was able to create a table with to_date and conversion as column names without quotation marks. A SELECT that specified the column names without quotation marks also retrieved the one inserted row.

CREATE TABLE upgtest.reserved_word_test (
  id INT PRIMARY KEY, to_date DATE, conversion VARCHAR(16)
);
SELECT id, to_date FROM upgtest.reserved_word_test;
-- 1 | 2026-08-12

For this instance, I specified 12.3.2 as the engine version with modify-db-instance and ran the in-place upgrade. If you are using a custom parameter group, you need to prepare a 12.3 family parameter group and swap it in (source: Major version upgrades for RDS for MariaDB, mentioned above).

The pre-upgrade check produced no warnings, including for reserved word incompatibilities, and the upgrade completed with the instance on 12.3.2.

Changes After the Upgrade

After the upgrade, VERSION() was 12.3.2-MariaDB-log. The one row in the existing table was preserved.

While the data was preserved, referencing the existing to_date column without quotation marks resulted in a syntax error.

SELECT id, to_date FROM upgtest.reserved_word_test
ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'FROM upgtest.reserved_word_test' at line 1

Referencing the conversion column without quotation marks also resulted in the same ERROR 1064. Both to_date and conversion could be referenced when enclosed in backticks.

On the other hand, the result of SHOW CREATE TABLE returned the column names as backtick-quoted identifiers both before and after the upgrade.

CREATE TABLE `reserved_word_test` (
  ...
  `to_date` date DEFAULT NULL,
  `conversion` varchar(16) DEFAULT NULL,
  ...
)

For read_only, both the value displayed in the DB and the values that can be set in the parameter group had changed. The result of SELECT @@global.read_only was 0 on 11.8.8 and OFF on 12.3.2.

The values that can be set in parameter groups also differ between families. In the 12.3 family, NO_LOCK could be set for read_only, but it was rejected in the 11.8 family. Meanwhile, for group_concat_max_len, 4294967296, which was accepted in the 11.8 family, was rejected as out of range in the 12.3 family.

Parameter 11.8 family 12.3 family
read_only 0 / 1 / {TrueIfReplica} ON / OFF / NO_LOCK / NO_LOCK_NO_ADMIN / {TrueIfReplica}
group_concat_max_len 4〜18446744073709547520 4〜1073741824

Specifying NO_LOCK for read_only in the 11.8 family produced the following error.

An error occurred (InvalidParameterValue) when calling the ModifyDBParameterGroup operation: Invalid boolean value: NO_LOCK

The value 4294967296 specified for group_concat_max_len in the 12.3 family was rejected as out of range.

An error occurred (InvalidParameterValue) when calling the ModifyDBParameterGroup operation: Value: 4294967296 is outside of range: 4-1073741824 for parameter: group_concat_max_len

Summary

When adopting RDS for MariaDB for a new deployment, you can consider MariaDB 12.3, which is an LTS release, as the first candidate.

On the other hand, when upgrading an existing environment in place, compatibility issues due to reserved words or parameter group settings may arise with 12.3. I recommend reproducing your actual workload on a test DB restored from a snapshot and checking in advance.

For environments already using Extended Support or those nearing the end of standard support, a major upgrade to 12.3 may be difficult. In that case, please consider 11.4 and 10.11 as upgrade target candidates too, and plan your upgrade with the end of support in mind.

Share this article

AWSのお困り事はクラスメソッドへ