Postgres 使用一种基于消息的协议用于前端和后端（服务器和客户机）之间通讯。 该协议是在 TCP/IP 和 Unix 域套接字上实现的。 端口号 5432 已经在 IANA 注册为使用这种协议的常用端口，但实际上任何非特权端口号都可以使用。
这份文档描述了版本 3.0 的协议，在 Postgres 版本 7.4 和以后的版本中实现。 对于以前的协议的描述，请参考以前版本的 PostgreSQL 文档。 一个服务器可以支持多种协议版本。初始化的启动信息告诉服务器客户端可以接受的协议版本，然后服务器则遵守该版本的协议——如果它能做到的话。
在这个协议的基础上建立的更高级特性（例如，libpq 是如何在建立联接以后传递某种环境变量的）在其他地方描述．
为了可以有效地为多个客户端提供服务，服务器为每个客户端派生一个新的"后端"进程。 在目前的实现里，在检测到到来的连接请求后，马上创建一个新的子进程。 不过，这些是对协议透明的。对于协议而言，术语"后端"和"服务器"是可以互换的； 类似的还有"前端"和"客户机"也是可以互换的。
协议在启动和正常操作过程中有不同的阶段。 在启动阶段里，前端打开一个到服务器的连接并且认证自身以满足服务器。 （这些可能包含一条消息，也可能包含多条消息，根据使用的认证方法而不同。） 如果所有这些事情都运行平稳，那么服务器就发送状态信息给前端，并最后进入正常操作。 除了初始化的启动请求之外，这部分协议是服务器驱动的。
在正常操作中，前端发送查询和其它命令到后端，然后后端返回查询结果和其它响应。 有少数几种情况（比如 NOTIFY）是后端发送主动提供的消息，但这部分的绝大多数情况都是由前端请求驱动的。
会话的终止通常是由前端来选择的，但是也可以在某些情况下由后端强制执行。 不管那种情况，如果后端关闭连接，那么他将在退出之前回滚（完成）所有打开的（未完成的）事务。
在正常操作中，SQL 命令可以通过两个子协议中的任何一个执行。 在"简单查询"协议中，前端只是发送一个文本查询串， 然后后端马上分析并执行它。在"扩展查询"协议中， 查询的处理被分割为多个步骤：分析，参数值绑定，和执行。 这样就可以提供灵活性和性能的改进，代价是额外的复杂性。
正常操作有用于类似 COPY 这样的额外的子协议。
所有通讯都是通过一个消息流进行的。消息的第一个字节标识消息类型， 然后后面跟着的四个字节声明消息剩下部分的长度（这个长度包括长度域自身，但是不包括消息类型字节）。 剩下的消息内容由消息类型决定。由于历史原因，客户端发送的最早的消息（启动消息）没有初始的消息类型字节。
为了避免和消息流丢失同步信息，服务器和客户端通常都是把整个消息读取到一个缓冲区里（使用字节计数）， 然后才试图处理其内容。这样我们在处理内容的过程中，如果发现错误，就比较容易恢复。 在非常罕见的情况下（比如说没有足够的信息缓冲消息），接收端可以使用字节计数来判断它在重新读取信息之前需要忽略多少输入。
通常，服务器和客户端都需要注意决不发送一条不完整的消息。 这些通常是通过在发送整条信息之前，在一个缓冲区里整理整条消息。 如果在发送或者接受一条消息的中间发生了通讯错误，那么唯一合理的反应是放弃连接，因为恢复消息边界同步的可能性很小。
在扩展查询协议中，SQL 命令的执行是分割成多个步骤的。 步骤与步骤之间保存的状态是由两类的对象代表的： 准备好的语句（prepared statements）和入口（portals）。 一个准备好的语句代表一个文本查询字串的经过分析，语意解析，以及规划之后的结果。 一个准备好的语句不一定就是可以执行的，因为它可能还缺乏 参数的值。 一个入口代表一个已经可以执行的或者已经部分执行过的语句，所有参数都已经填充到位了。 （对于SELECT语句，入口等效于一个打开的游标， 我们使用不同的术语是因为游标不能处理非SELECT语句。）
完整的执行周期包括一个分析步骤， 它从一个文本的查询字串里创建一个准备好的语句； 一个绑定（bind）步骤， 它用一个准备好的语句和任何所需要的参数值创建一个入口；以及一个 执行（execute）步骤，它运行一个入口的查询。 如果是一个返回数据行的查询（SELECT，SHOW 等）， 系统可以告诉执行步骤只抓取有限的一些行，这样就可能需要多个执行步骤来完成操作。
后端可以跟踪多个准备好的语句和入口（但是要注意，这些只在一个会话内部存在，从来不能在会话之间共享）。 现存的准备好地语句和入口都是用创建它们的时候赋予的名字引用的。 另外，还存在一个"未命名（unnamed）" 的准备好语句和入口。 尽管它们的行为和命名对象大部分相同，但是它们是针对只执行一次然后就抛弃的查询进行优化过的， 而在命名对象上的操作是针对多次使用优化的。
特定数据类型的数据可以用几种不同的格式中的任意一种来传递。 到 PostgreSQL 7.4 的时候，只支持"文本"和"二进制"两种格式， 但是协议为未来的扩展提供了的手段。任意值要求的格式是用一个格式代码声明的。 客户端可以为每个传输的参数值和查询结果的每个字段声明一个格式代码。 文本的格式代码是零，二进制的格式代码是一，所有其它的格式代码都保留给将来定义。
文本方式的数值是特定数据类型的输入/输出转换函数接受或者生成的数值的字串形式。 在传输表现上，字串末尾没有空字符；如果前端要想把收到的值当作 C 字串处理，那么必须自己加上一个。 （另外，文本格式不允许嵌入的空。）
整数的二进制表现形式采用网络字节序（高位在前）。对于其它数据类型， 情参考文档或者源代码获取其二进制表现形式的信息。请注意，复杂的数据类型的二进制形式可能在不同服务器版本之间变化； 文本格式通常是最具有移植性的选择。