diff --git a/content/200-orm/100-prisma-schema/50-introspection.mdx b/content/200-orm/100-prisma-schema/50-introspection.mdx
index 1ebae42b3c..fea51a3b60 100644
--- a/content/200-orm/100-prisma-schema/50-introspection.mdx
+++ b/content/200-orm/100-prisma-schema/50-introspection.mdx
@@ -29,8 +29,7 @@ Here's an overview of its main functions on SQL databases:
 
 On MongoDB, the main functions are the following:
 
-- Map _collections_ in the database to [Prisma models](/orm/prisma-schema/data-model/models#defining-models)
-- Map _documents_ in the collections to the [fields](/orm/prisma-schema/data-model/models#defining-fields) of Prisma models by _sampling them_
+- Map _collections_ in the database to [Prisma models](/orm/prisma-schema/data-model/models#defining-models). Because a _collection_ in MongoDB doesn't have a predefined structure, Prisma ORM _samples_ the _documents_ in the collection and derives the model structure accordingly (i.e. it maps the fields of the _document_ to the [fields](/orm/prisma-schema/data-model/models#defining-fields) of the Prisma model). If _embedded types_ are detected in a collection, these will be mapped to [composite types](/orm/prisma-schema/data-model/models#defining-composite-types) in the Prisma schema.
 - Map _indexes_ in the database to [indexes](/orm/prisma-schema/data-model/models#defining-an-index) in the Prisma schema, if the collection contains at least one document contains a field included in the index
 
 You can learn more about how Prisma ORM maps types from the database to the types available in the Prisma schema on the respective docs page for the data source connector:
diff --git a/content/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx b/content/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx
index 6c5c39a7b5..965f49571c 100644
--- a/content/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx
+++ b/content/200-orm/200-prisma-client/100-queries/100-query-optimization-performance.mdx
@@ -36,7 +36,11 @@ The n+1 problem occurs when you loop through the results of a query and perform
 
 </div>
 
-The Prisma Client dataloader automatically **batches** `findUnique()` queries that ✔ occur in the same tick and ✔ have the same `where` and `include` parameters.
+The Prisma Client dataloader automatically _batches_ `findUnique()` queries that occur in the same [tick](https://nodejs.org/en/learn/asynchronous-work/event-loop-timers-and-nexttick#processnexttick) and have the same `where` and `include` parameters if:
+
+- All criteria of the `where` filter are on scalar fields (unique or non-unique) of the same model you're querying.
+- All criteria use the `equal` filter, whether that's via the shorthand or explicit syntax `(where: { field: <val>, field1: { equals: <val> } })`.
+- No boolean operators or relation filters are present.
 
 Automatic batching of `findUnique()` is particularly useful in a **GraphQL context**. GraphQL runs a separate resolver function for every field, which can make it difficult to optimize a nested query.