diff --git a/django/contrib/postgres/operations.py b/django/contrib/postgres/operations.py
index c09d7874c193..b760b32a230e 100644
--- a/django/contrib/postgres/operations.py
+++ b/django/contrib/postgres/operations.py
@@ -43,7 +43,7 @@ def database_forwards(self, app_label, schema_editor, from_state, to_state):
             )
 
     def database_backwards(self, app_label, schema_editor, from_state, to_state):
-        if not router.allow_migrate(
+        if schema_editor.connection.vendor != "postgresql" or not router.allow_migrate(
             schema_editor.connection.alias, app_label, **self.hints
         ):
             return
diff --git a/docs/intro/tutorial02.txt b/docs/intro/tutorial02.txt
index a62d59e4ac42..b93f5d8a38bf 100644
--- a/docs/intro/tutorial02.txt
+++ b/docs/intro/tutorial02.txt
@@ -95,10 +95,9 @@ additional metadata.
    Django follows the :ref:`DRY Principle <dry>`. The goal is to define your
    data model in one place and automatically derive things from it.
 
-   This includes the migrations - unlike in Ruby On Rails, for example,
-   migrations are entirely derived from your models file, and are essentially a
-   history that Django can roll through to update your database schema to
-   match your current models.
+   This includes the migrations, which are derived from your models file.
+   They form a history that Django uses to update your database schema
+   to match your current models.
 
 In our poll app, we'll create two models: ``Question`` and ``Choice``. A
 ``Question`` has a question and a publication date. A ``Choice`` has two