A GraphQL schema created by reflection over a PostgreSQL schema.
Stable: v3 (master branch) - maintenance only
Next: v4 (postgraphile branch) - PostGraphQL is being renamed PostGraphile with the launch of v4; see graphile.org for docs; see #506 for the low-down.
The strongly typed GraphQL data querying language is a revolutionary new way to interact with your server. Similar to how JSON very quickly overtook XML, GraphQL will likely take over REST. Why? Because GraphQL allows us to express our data in the exact same way we think about it.
The PostgreSQL database is the self acclaimed “world’s most advanced open source database” and even after 20 years that still rings true. PostgreSQL is the most feature rich SQL database available and provides an excellent public reflection API giving its users a lot of power over their data. And despite being 20 years old, the database still has frequent releases.
With PostGraphQL, you can access the power of PostgreSQL through a well designed GraphQL server. PostGraphQL uses PostgreSQL reflection APIs to automatically detect primary keys, relationships, types, comments, and more providing a GraphQL server that is highly intelligent about your data.
PostGraphQL holds a fundamental belief that a well designed database schema should be all you need to serve well thought out APIs. PostgreSQL already has amazing user management and relationship infrastructure, why duplicate that logic in a custom API? PostGraphQL is likely to provide a more performant and standards compliant GraphQL API then any created in house. Focus on your product and let PostGraphQL manage how the data gets to the product.
For a critical evaluation of PostGraphQL to determine if it fits in your tech stack, read the evaluating PostGraphQL for your project section.
Watch a talk by the original author Caleb at GraphQL Summit for a fast 7 minute introduction to using the PostGraphQL project.
First install using npm:
npm install -g postgraphql…and then just run it! By default, PostGraphQL will connect to your local database at postgres://localhost:5432 and introspect the public schema.
postgraphqlFor information about how to change these defaults, just run:
postgraphql --helpYou can also use PostGraphQL as native HTTP, Connect, Express, or Koa middleware. Just import postgraphql:
import { createServer } from 'http'
import postgraphql from 'postgraphql'
createServer(postgraphql())For more information around using PostGraphQL as a library, and the options the API expects read the library usage documentation article.
There is also a docker image for running PostGraphQL maintained by @angelosarto, simply pass the same options to the docker container:
docker pull postgraphql/postgraphql
docker run postgraphql/postgraphql --helpTo connect to a database and expose the PostGraphQL port try this:
docker run -p 5000:5000 postgraphql/postgraphql --connection postgres://POSTGRES_USER:POSTGRES_PASSWORD@POSTGRES_HOST:POSTGRES_PORT/POSTGRES_SCHEMAAlso make sure to check out the forum example and especially step by step tutorial for a demo of a PostGraphQL compliant schema and authentication.
PostGraphQL uses the joint benefits of PostgreSQL and GraphQL to provide a number of key benefits.
Does your table’s authorId column reference another table? PostGraphQL knows and will give you a field for easily querying that reference.
A schema like:
create table post (
id serial primary key,
author_id int non null references user(id),
headline text,
body text,
...
);Can query relations like so:
{
allPosts {
edges {
node {
headline
body
author: userByAuthorId {
name
}
}
}
}
}Procedures in PostgreSQL are powerful for writing business logic in your database schema, and PostGraphQL allows you to access those procedures through a GraphQL interface. Create a custom mutation, write an advanced SQL query, or even extend your tables with computed columns! Procedures allow you to write logic for your app in SQL instead of in the client all while being accessible through the GraphQL interface.
So a search query could be written like this:
create function search_posts(search text) returns setof post as $$
select *
from post
where
headline ilike ('%' || search || '%') or
body ilike ('%' || search || '%')
$$ language sql stable;And queried through GraphQL like this:
{
searchPosts(search: "Hello world", first: 5) {
pageInfo {
hasNextPage
}
totalCount
edges {
cursor
node {
headline
body
}
}
}
}For more information, check out our procedure documentation and our advanced queries documentation.
Running PostGraphQL in watch mode will get you the best experience for iterating on a GraphQL API in the whole GraphQL ecosystem.
postgraphql --watch
PostGraphQL will watch your Postgres database for changes. New tables, updated columns, new procedures, and more! When these changes are detected PostGraphQL will re-create your schema and will automatically update any opened GraphiQL windows with the new schema while preserving your navigation state in the documentation viewer.
Introspection of a GraphQL schema is powerful for developer tooling and one element of introspection is that every type in GraphQL has an associated description field. As PostgreSQL allows you to document your database objects, naturally PostGraphQL exposes these documentation comments through GraphQL.
Documenting PostgreSQL objects with the COMMENT command like so:
create table user (
username text non null unique,
...
);
comment on table user is 'A human user of the forum.';
comment on column user.username is 'A unique name selected by the user to represent them on our site.';Will let you reflect on the schema and get the JSON below:
{
__type(name: "User") { ... }
}{
"__type": {
"name": "User",
"description": "A human user of the forum.",
"fields": {
"username": {
"name": "username",
"description": "A unique name selected by the user to represent them on our site."
}
}
}
}GraphiQL is a great tool by Facebook to let you interactively explore your data. When development mode is enabled in PostGraphQL, the GraphiQL interface will be automatically displayed at your GraphQL endpoint.
Just navigate with your browser to the URL printed to your console after starting PostGraphQL and use GraphiQL with your data! Even if you don’t want to use GraphQL in your app, this is a great interface for working with any PostgreSQL database.
PostGraphQL lets you use token based authentication with JSON Web Tokens (JWT) to secure your API. It doesn’t make sense to redefine your authentication in the API layer, instead just put your authorization logic in the database schema! With an advanced grants system and row level security, authorization in PostgreSQL is more than enough for your needs.
PostGraphQL follows the PostgreSQL JSON Web Token Serialization Specification for serializing JWTs to the database for your use in authorization. The role claim of your JWT will become your PostgreSQL role and all other claims can be found under the jwt.claims namespace (see retrieving claims in PostgreSQL).
To enable token based authorization use the --secret <string> command line argument with a secure string PostGraphQL will use to sign and verify tokens. And if you don’t want authorization, just don’t set the --secret argument and PostGraphQL will ignore all authorization information!
There are some problems with traditional limit/offset pagination and realtime data. For more information on such problems, read this article.
PostGraphQL not only provides limit/offset pagination, but it also provides cursor based pagination ordering on the column of your choice. Never again skip an item with free cursor based pagination!
You don’t have to use GraphQL with React and Relay, but if you are, PostGraphQL implements the brilliant Relay specifications for GraphQL. Even if you are not using Relay your project will benefit from having these strong, well thought out specifications implemented by PostGraphQL.
The specific specs PostGraphQL implements are:
- Global Object Identification Specification.
- Cursor Connections Specification.
- Input Object Mutations Specification.
- Using PostGraphQL as Express, Connect, or Koa middleware.
- Adding advanced queries to PostGraphQL.
- Using PostgreSQL functions to extend your PostGraphQL schema.
- A crash course in PostgreSQL roles for PostGraphQL.
Hopefully you’ve been convinced that PostGraphQL serves an awesome GraphQL API, but now let’s take a more critical look at whether or not you should adopt PostGraphQL for your project.
PostGraphQL’s audience is for people whose core business is not the API and want to prioritize their product. PostGraphQL allows you to define your content model in the database as you normally would, however instead of building the bindings to the database (your API) PostGraphQL takes care of it.
This takes a huge maintenance burden off your shoulders. Now you don’t have to worry about optimizing the API and the database, instead you can focus on just optimizing your database.
PostGraphQL does not lock you into using PostGraphQL forever. Its purpose is to help your business in a transitory period. When you feel comfortable with the cost of building your API PostGraphQL is simple to switch with a custom solution.
How is it simple? Well first of all, your PostgreSQL schema is still your PostgreSQL schema. PostGraphQL does not ask you to do anything too divergent with your schema allowing you to take your schema (and all your data) to whatever solution you build next. GraphQL itself provides a simple and clear deprecation path if you want to start using different fields.
Ideally PostGraphQL scales with your company and we would appreciate your contributions to help it scale, however there is a simple exit path even years into the business.
If you fundamentally disagree with a one-to-one mapping of a SQL schema to an API (GraphQL or otherwise) this section is for you. First of all, PostGraphQL is not necessarily meant to be a permanent solution. PostGraphQL was created to allow you to focus on your product and not the API. If you want a custom API there is a simple transition path (read no lock in). If you still can’t get over the one-to-one nature of PostGraphQL consider the following arguments why putting your business logic in PostgreSQL is a good idea:
- PostgreSQL already has a powerful user management system with fine grained row level security. A custom API would mean you have to build your own user management and security.
- PostgreSQL allows you to hide implementation details with views of your data. Simple views can even be auto-updatable. This provides you with the same freedom and flexibility as you might want from a custom API except more performant.
- PostgreSQL gives you automatic relations with the
REFERENCESconstraint and PostGraphQL automatically detects them. With a custom API, you’d need to hardcode these relationships. - For what it’s worth, you can write in your favorite scripting language in PostgreSQL including JavaScript and Ruby.
- And if you don’t want to write your Ruby in PostgreSQL, you could also use PostgreSQL’s
NOTIFYfeature to fire events to a listening Ruby or JavaScript microservice can listen and respond to PostgreSQL events (this could include email transactions and event reporting).
Still worried about a certain aspect of a schema driven API? Open an issue, confident we can convince you otherwise 😉
Want to help testing and developing PostGraphQL? Check out the contributing document to get started quickly!
The current maintainer of this project is Benjie Gillam.
Thanks so much to the people working on PostgREST which was definetly a huge inspiration for this project! The core contributors are awesome and taught us so much 😊. Ironically, they also convinced us that GraphQL was superior to REST…
A humongous, heart-felt, thank you to the original author of PostGraphQL - Caleb Meredith - for everything he put into PostGraphQL! He's now graduated from the project and we all wish him the best for his future ventures!
Even more thanks to each and every sponsor of the project - without their help progress would be a lot slower!
Thanks and enjoy 👍