Amazon RDS for MariaDB 12.3 Is Now Generally Available (GA), So I Tried It Out
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.
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.
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_DATEandCONVERSION(Upgrading from MariaDB 11.8 to MariaDB 12.3) - The default value of
innodb_snapshot_isolationis nowON. Applications that depend on the transaction isolation level need to be tested (MariaDB Foundation announcement) big_tables/storage_engine/large_page_sizewere removed (the upgrade guide above)- On replicas, the
master_use_gtidsetting is not carried over and is reset toDEFAULT. 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.
