Yes. See the API documentation for ConnectionPool.
ConnectionPool provides an asynchronous API to service a large number of requests using a small number of shared Connection instances and threads. This is useful for server-side Swift.
Connection (together with Statement and Cursor) provide a synchronous API for performing a SQL statement. This makes it easy to sequence the steps in preparing and executing a SQL statement, processing the rows it returns, and handling any errors on the way.
Concurrency is an evolving area in Swift. It will be interesting to see what ideas gain traction.
Postgres doesn't require the columns returned by a SELECT to be uniquely named (for example, in queries with joins or computed columns). Name-based access is better left to a higher level, such as an object-relational mapper.
That said, as of v1.5.0, PostgresClientKit can decode a row into a Swift type that conforms to the Decodable protocol, mapping columns to stored properties by either by or by position. See the API documentation for Row.decodeByColumnName(_:defaultTimeZone) and Row.decodeByColumnIndex(_:defaultTimeZone).
To make Postgres-to-Swift type conversion explicit and robust, PostgresClientKit defers to the developer. Should a SQL NUMERIC map to a Swift Int, Double, or Decimal? Should a SQL VARCHAR map to a Swift String or an Optional<String>? Answering these questions requires domain knowledge, which may not be encoded in the SQL data model, but which the developer (hopefully) has.