diff --git a/README.md b/README.md
index 1fa74f6..79a76c4 100644
--- a/README.md
+++ b/README.md
@@ -123,6 +123,37 @@ r = MyRecord.new(id: 1, name: 'bar')
 r.upsert!
 ```
 
+### Gotcha with database defaults
+
+When a table is defined with a database default for a field, this gotcha can occur when trying to explicitly upsert a record _to_ the default value (from a non-default value).
+
+**Example**: a table called `hardwares` has a `prio` column with a default value.
+
+    ┌─────────┬─────────┬───────┬
+    │ Column  │ Type    │Default│
+    ├─────────┼─────────┼───────┼
+    │ id      │ integer │ ...
+    │ prio    │ integer │ 999
+
+And `hardwares` has a record with a non-default value for `prio`. Say, the record with `id` 1 has a `prio` of `998`. 
+
+In this situation, upserting like:
+
+```ruby
+hw = { id: 1, prio: 999 }
+Hardware.new(prio: hw[:prio]).upsert
+```
+
+will not mention the `prio` column in the `ON CONFLICT` clause, resulting in no update.
+
+However, upserting like so:
+
+```ruby
+Hardware.upsert(prio: hw[:prio]).id
+```
+
+will indeed update the record in the database back to its default value, `999`.
+
 ### Conflict Clauses
 
 It's possible to specify which columns should be used for the conflict clause. **These must comprise a unique index in Postgres.**