The four pillars at a glance

pgRDF is one PostgreSQL extension with four parts under the pgrdf schema. They share one set of graphs: the graph you load is the one you query, reason over, and validate.

Pillar	What it gives you	Main functions
1 · Storage	RDF in dictionary-encoded PostgreSQL tables, one partition per named graph. Load Turtle, TriG or N-Quads from a string or a file on the server. The staged loader loads large N-Triples dumps in parallel.	add_graph, parse_turtle, parse_trig, parse_nquads, load_turtle, load_turtle_staged_run
2 · Query	SPARQL 1.1 SELECT, ASK, CONSTRUCT, DESCRIBE and UPDATE: joins, FILTER, OPTIONAL, UNION, MINUS, VALUES, BIND, subqueries, aggregates, ORDER BY, GRAPH, property paths. Results are JSONB rows you can join with SQL. Some constructs are not supported.	sparql, construct, describe
3 · Reasoning	OWL 2 RL or RDFS forward chaining. Inferred triples are stored beside the asserted ones, visible to queries and validation, and replaced on each run.	materialize
4 · Validation	SHACL Core (the W3C Core test suite passes 25/25), plus SHACL-SPARQL constraints in 'pgrdf' mode. The report is JSONB you can store, query, or use to gate a load.	validate

One workflow, all four

This runs on any server with pgRDF installed and pgrdf in shared_preload_libraries (see Install). It uses inline data, so there are no files to copy.

CREATE EXTENSION IF NOT EXISTS pgrdf;

-- 1. Storage: a data graph and a shapes graph.
SELECT pgrdf.add_graph('https://example.com/graph/orders');
SELECT pgrdf.add_graph('https://example.com/graph/order-shapes');

SELECT pgrdf.parse_turtle($$
@prefix ex:   <http://example.com/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
ex:BulkOrder rdfs:subClassOf ex:Order .
ex:o1 a ex:BulkOrder ; ex:placedBy ex:acme   ; ex:total 1500 .
ex:o2 a ex:Order     ; ex:placedBy ex:globex ; ex:total 250 .
ex:o3 a ex:BulkOrder ;                         ex:total 4200 .
$$, pgrdf.graph_id('https://example.com/graph/orders'));

SELECT pgrdf.parse_turtle($$
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix ex: <http://example.com/> .
ex:OrderShape a sh:NodeShape ;
  sh:targetClass ex:Order ;
  sh:property [ sh:path ex:placedBy ; sh:minCount 1 ] .
$$, pgrdf.graph_id('https://example.com/graph/order-shapes'));

-- 2. Reasoning: every BulkOrder is also an Order.
SELECT pgrdf.materialize(pgrdf.graph_id('https://example.com/graph/orders'))
       -> 'inferred_triples_written';
-- 10

-- 3. Validation: the shape targets ex:Order, which o3 only is by inference.
SELECT r->>'focusNode' AS focus, r->>'resultMessage' AS message
  FROM jsonb_array_elements(
         pgrdf.validate(pgrdf.graph_id('https://example.com/graph/orders'),
                        pgrdf.graph_id('https://example.com/graph/order-shapes'))
         -> 'results') AS r;
--          focus         |          message
-- -----------------------+---------------------------
--  http://example.com/o3 | MinCount(1) not satisfied

-- 4. Query: large orders, including the inferred ones.
SELECT sparql->>'order' AS "order", sparql->>'total' AS total
  FROM pgrdf.sparql($$
    PREFIX ex: <http://example.com/>
    SELECT ?order ?total
     WHERE { ?order a ex:Order ; ex:total ?total
             FILTER(?total > 1000) }
     ORDER BY ?total
  $$);
--          order         | total
-- -----------------------+-------
--  http://example.com/o1 | 1500
--  http://example.com/o3 | 4200

Run validate before materialize and the graph conforms: without reasoning, nothing tells the validator that o3 is an order.

How each part scales

• Loading scales with cores. The staged loader spreads its work over a pool of background workers; it has loaded the complete 8.2-billion-triple Wikidata truthy dump into one instance (see Scale & benchmarks).
• Reasoning and validation run in one backend. Size the graph you reason over to the machine: carve the part you need into its own graph with carve_graph (see Graphs) and materialize that. Processes & flows walks through the patterns.

Beyond the four pillars

• account_tree Graphs: inventory, copy and move, locks, and carving one graph out of another.
• verified Identity: canonical digests, manifests and N-Triples export for proving what a graph contains.
• fact_check Errors and diagnostics: SQLSTATE codes, completeness checks, settings, and what the server supports.

Take the ten-minute tour → · Pillar 1 · Storage →