SAP HANA Permissions

Qualytics connects to SAP HANA using the official SAP HANA JDBC driver (ngdbc) with basic username and password authentication. Every catalog, profile, and scan operation runs as the HANA user supplied in the connection form, so that user needs read access to the schema you want to monitor and to a small set of HANA system views.

Minimum HANA Privileges

The connection user needs the privileges in the table below. Grant them through the role you assign to the user, or directly to the user.

Privilege	Object	Purpose
SELECT	Each table or view Qualytics monitors	Profile and scan source rows
SELECT	Target schema (schema-level grant)	Discover tables and views in the schema when adding the datastore
SELECT on SYS.SCHEMAS	System view	List schemas in the Schema dropdown
SELECT on SYS.TABLES / SYS.VIEWS	System views	List tables and views in each schema
SELECT on SYS.TABLE_COLUMNS / SYS.VIEW_COLUMNS	System views	Read column names, types, nullability, and length
SELECT on SYS.CONSTRAINTS	System view	Read primary-key and not-null constraints used for profiling

Built-in roles

On most HANA deployments, the predefined PUBLIC role already grants SELECT on the SYS views the connector needs. If your security team has revoked or restricted PUBLIC, grant SELECT on those views explicitly. Object-level SELECT on application schemas is never part of PUBLIC and must be granted separately.

Schema-Level Grant

Granting SELECT on the schema is the most common setup. It lets Qualytics see every existing and future table without re-granting after each new object:

CREATE USER qualytics_reader PASSWORD "<strong-password>" NO FORCE_FIRST_PASSWORD_CHANGE;
GRANT SELECT ON SCHEMA "SALES" TO qualytics_reader;

Replace SALES with the schema you plan to expose, and qualytics_reader with the user you create for the connection. HANA stores unquoted identifiers in upper case, so double-quote the schema name only when it was created with mixed case.

Object-Level Grants

If you cannot grant schema-wide read access, grant SELECT on each individual table and view:

GRANT SELECT ON "SALES"."CUSTOMERS" TO qualytics_reader;
GRANT SELECT ON "SALES"."ORDERS" TO qualytics_reader;

You also need to grant SELECT on the system views above so the connector can discover columns and constraints. Without these grants, the Schema and Container dropdowns will be empty and profile jobs will fail with Sql exception: invalid schema name.

HANA Cloud vs On-Premises

Topic	HANA Cloud	On-Premises
User type	Database user inside the tenant database	Database user inside the chosen tenant (or system database)
Default authentication	Basic (username / password)	Basic (username / password)
Schema visibility	Limited to schemas inside the tenant addressed by the hostname	Limited to schemas inside the tenant named in the Database field
TLS	Always on, certificate validated	On by default, can be disabled per deployment policy

Tenant scope

On a multi-tenant on-premises HANA, a user exists inside a single tenant database. The user supplied to Qualytics can only see schemas inside that tenant; pointing the connection at a different tenant requires creating a new HANA user there.

Privileges Qualytics Never Needs

The connection user does not need:

• CREATE / DROP on the source schema. Qualytics never creates, alters, or drops source objects.
• INSERT / UPDATE / DELETE on source tables. All source operations are SELECT-only.
• Administrative roles such as DATA ADMIN, BACKUP ADMIN, or SYSTEM. These grant far more than the connector requires and should not be assigned for least-privilege reasons.

If you also use SAP HANA as an enrichment datastore, the enrichment user (separate from the read-only user above) does need CREATE, INSERT, UPDATE, and DELETE on its own enrichment schema so Qualytics can write anomalies and metadata. Use a separate HANA user for enrichment to keep source and enrichment privileges isolated.