1 files changed, 18 insertions, 1 deletions
diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md
index 96803746637..481eb692674 100644
--- a/doc/administration/high_availability/nfs.md
+++ b/doc/administration/high_availability/nfs.md
@@ -61,7 +61,7 @@ on an Linux NFS server, do the following:
 
 2. Restart the NFS server process. For example, on CentOS run `service nfs restart`.
 
-## AWS Elastic File System
+## Avoid using AWS's Elastic File System (EFS)
 
 GitLab strongly recommends against using AWS Elastic File System (EFS).
 Our support team will not be able to assist on performance issues related to
@@ -78,6 +78,23 @@ stored on a local volume.
 For more details on another person's experience with EFS, see
 [Amazon's Elastic File System: Burst Credits](https://rawkode.com/2017/04/16/amazons-elastic-file-system-burst-credits/)
 
+## Avoid using PostgreSQL with NFS
+
+GitLab strongly recommends against running your PostgreSQL database
+across NFS. The GitLab support team will not be able to assist on performance issues related to
+this configuration.
+
+Additionally, this configuration is specifically warned against in the
+[Postgres Documentation](https://www.postgresql.org/docs/current/static/creating-cluster.html#CREATING-CLUSTER-NFS):
+
+>PostgreSQL does nothing special for NFS file systems, meaning it assumes NFS behaves exactly like 
+>locally-connected drives. If the client or server NFS implementation does not provide standard file 
+>system semantics, this can cause reliability problems. Specifically, delayed (asynchronous) writes 
+>to the NFS server can cause data corruption problems.
+
+For supported database architecture, please see our documentation on 
+[Configuring a Database for GitLab HA](https://docs.gitlab.com/ee/administration/high_availability/database.html).
+
 ## NFS Client mount options
 
 Below is an example of an NFS mount point defined in `/etc/fstab` we use on