diff --git a/changelog/18.0/18.0.3/changelog.md b/changelog/18.0/18.0.3/changelog.md
new file mode 100644
index 00000000000..2e245c32176
--- /dev/null
+++ b/changelog/18.0/18.0.3/changelog.md
@@ -0,0 +1,6 @@
+# Changelog of Vitess v18.0.3
+
+### Release 
+#### General
+ * [release-18.0] Code Freeze for `v18.0.3` [#227](https://github.com/frouioui/vitess/pull/227)
+
diff --git a/changelog/18.0/18.0.3/release_notes.md b/changelog/18.0/18.0.3/release_notes.md
new file mode 100644
index 00000000000..41dfdbde36f
--- /dev/null
+++ b/changelog/18.0/18.0.3/release_notes.md
@@ -0,0 +1,34 @@
+# Release of Vitess v18.0.3
+## Summary
+
+### Table of Contents
+
+- **[Major Changes](#major-changes)**
+  - **[Breaking Changes](#breaking-changes)**
+    - [ExecuteFetchAsDBA rejects multi-statement SQL](#execute-fetch-as-dba-reject-multi)
+
+## <a id="major-changes"/>Major Changes
+
+### <a id="breaking-changes"/>Breaking Changes
+
+#### <a id="execute-fetch-as-dba-reject-multi"/>ExecuteFetchAsDBA rejects multi-statement SQL
+
+`vtctldclient ExecuteFetchAsDBA` (and similarly the `vtctl` and `vtctlclient` commands) now reject multi-statement SQL with error.
+
+For example, `vtctldclient ExecuteFetchAsDBA my-tablet "stop replica; change replication source to auto_position=1; start replica` will return an error, without attempting to execute any of these queries.
+
+Previously, `ExecuteFetchAsDBA` silently accepted multi statement SQL. It would (attempt to) execute all of them, but:
+
+- It would only indicate error for the first statement. Errors on 2nd, 3rd, ... statements were silently ignored.
+- It would not consume the result sets of the 2nd, 3rd, ... statements. It would then return the used connection to the pool in a dirty state. Any further query that happens to take that connection out of the pool could get unexpected results.
+- As another side effect, multi-statement schema changes would cause schema to be reloaded with only the first change, leaving the cached schema inconsistent with the underlying database.
+
+`ExecuteFetchAsDBA` does allow a specific use case of multi-statement SQL, which is where all statements are in the form of `CREATE TABLE` or `CREATE VIEW`. This is to support a common pattern of schema initialization, formalized in `ApplySchema --batch-size` which uses `ExecuteFetchAsDBA` under the hood.
+
+------------
+The entire changelog for this release can be found [here](https://github.com/frouioui/vitess/blob/main/changelog/18.0/18.0.3/changelog.md).
+
+The release includes 1 merged Pull Requests.
+
+Thanks to all our contributors: @frouioui
+
diff --git a/changelog/18.0/18.0.3/summary.md b/changelog/18.0/18.0.3/summary.md
new file mode 100644
index 00000000000..1573ac0c0e3
--- /dev/null
+++ b/changelog/18.0/18.0.3/summary.md
@@ -0,0 +1,25 @@
+## Summary
+
+### Table of Contents
+
+- **[Major Changes](#major-changes)**
+  - **[Breaking Changes](#breaking-changes)**
+    - [ExecuteFetchAsDBA rejects multi-statement SQL](#execute-fetch-as-dba-reject-multi)
+
+## <a id="major-changes"/>Major Changes
+
+### <a id="breaking-changes"/>Breaking Changes
+
+#### <a id="execute-fetch-as-dba-reject-multi"/>ExecuteFetchAsDBA rejects multi-statement SQL
+
+`vtctldclient ExecuteFetchAsDBA` (and similarly the `vtctl` and `vtctlclient` commands) now reject multi-statement SQL with error.
+
+For example, `vtctldclient ExecuteFetchAsDBA my-tablet "stop replica; change replication source to auto_position=1; start replica` will return an error, without attempting to execute any of these queries.
+
+Previously, `ExecuteFetchAsDBA` silently accepted multi statement SQL. It would (attempt to) execute all of them, but:
+
+- It would only indicate error for the first statement. Errors on 2nd, 3rd, ... statements were silently ignored.
+- It would not consume the result sets of the 2nd, 3rd, ... statements. It would then return the used connection to the pool in a dirty state. Any further query that happens to take that connection out of the pool could get unexpected results.
+- As another side effect, multi-statement schema changes would cause schema to be reloaded with only the first change, leaving the cached schema inconsistent with the underlying database.
+
+`ExecuteFetchAsDBA` does allow a specific use case of multi-statement SQL, which is where all statements are in the form of `CREATE TABLE` or `CREATE VIEW`. This is to support a common pattern of schema initialization, formalized in `ApplySchema --batch-size` which uses `ExecuteFetchAsDBA` under the hood.
diff --git a/changelog/18.0/README.md b/changelog/18.0/README.md
index 625ff947c5c..b02ee6b707a 100644
--- a/changelog/18.0/README.md
+++ b/changelog/18.0/README.md
@@ -1,4 +1,8 @@
 ## v18.0
+* **[18.0.3](18.0.3)**
+	* [Changelog](18.0.3/changelog.md)
+	* [Release Notes](18.0.3/release_notes.md)
+
 * **[18.0.2](18.0.2)**
 	* [Changelog](18.0.2/changelog.md)
 	* [Release Notes](18.0.2/release_notes.md)