Access Control

AkasicDB uses PostgreSQL schema and table privileges to provide graph-level access control.

Graph-Level Access Control

Each graph uses a PostgreSQL schema with the same name as the graph. To grant access to a graph, grant the required privileges on both the graph schema and all tables contained in it. A schema privilege does not grant privileges on the tables within that schema.

Default Permissions

When akasicdb.create_graph creates a graph, it grants the following permissions:

• PUBLIC receives USAGE on the graph schema and SELECT on all graph tables. Because every database role is a member of PUBLIC, every role can read the graph by default.
• The session_user that calls akasicdb.create_graph receives CREATE on the graph schema and becomes the owner of all graph tables. As the table owner, that role can read, write, and manage the graph tables.

akasicdb.create_graph does not grant table write permissions to PUBLIC. Roles other than the graph creator require explicit INSERT, UPDATE, or DELETE privileges to modify graph data, unless they receive those privileges through role membership or another grant. Superusers retain their inherent access.

Note

These default permissions and related behavior may change in a future AkasicDB version. Do not rely on the defaults as a stable access-control policy. Apply explicit grants and revocations for each graph, and verify them after upgrading AkasicDB.

Grant Role-Specific Access

To restrict graph reads to explicitly authorized roles, first revoke the default SELECT privilege from PUBLIC:

REVOKE SELECT ON ALL TABLES IN SCHEMA community_graph FROM PUBLIC;

PUBLIC retains USAGE on the graph schema, but schema USAGE alone does not allow a role to read or modify its tables.

The following statements grant graph_reader read-only access to the community_graph graph:

CREATE ROLE graph_reader;

GRANT USAGE ON SCHEMA community_graph TO graph_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA community_graph TO graph_reader;

To grant graph_writer permission to read and modify graph data without allowing it to create objects in the graph schema:

CREATE ROLE graph_writer;

GRANT USAGE ON SCHEMA community_graph TO graph_writer;
GRANT SELECT, INSERT, UPDATE, DELETE
    ON ALL TABLES IN SCHEMA community_graph
    TO graph_writer;

To revoke the explicitly granted access:

REVOKE ALL PRIVILEGES
    ON ALL TABLES IN SCHEMA community_graph
    FROM graph_reader, graph_writer;

REVOKE ALL PRIVILEGES
    ON SCHEMA community_graph
    FROM graph_reader, graph_writer;

A role may still receive access through membership in another role or through PUBLIC. Revoking a role's explicit privileges does not revoke privileges that it receives through those paths.

Warning

Recreating a graph with akasicdb.create_graph(..., replace_if_exists => true) reapplies the default privileges, including SELECT for PUBLIC. Custom grants and revocations on the previous graph are not preserved. Reapply access restrictions and role-specific grants after recreating the graph.

Limitations

Warning

Access restrictions do not guarantee that the existence of a graph or label is hidden from unauthorized roles.

Using PostgreSQL Row-Level Security (RLS) to restrict individual vertices or edges within a shared graph is not supported as a security boundary.

When strict data-access isolation is required between users or tenants, use separate graphs and apply graph-level privileges to each graph.