Create a Database User & Grant Permissions

How to create a user in each database

The idea is the same everywhere — an identity, a password (or an OS/identity provider), and a narrow set of privileges — but the syntax differs. Here are the canonical patterns the generator produces.

MySQL & MariaDB

Identity is a user@host pair, so the same username from a different host is a different account. Grant privileges per database, and only FLUSH PRIVILEGES if you edited the grant tables directly.

CREATE USER 'app_user'@'%' IDENTIFIED BY '••••••';
GRANT SELECT, INSERT, UPDATE, DELETE ON `app_db`.* TO 'app_user'@'%';

PostgreSQL

Roles are cluster-wide, so grant CONNECT on the database, USAGE on the schema, and privileges on the tables. Client host/IP rules live in pg_hba.conf, not in SQL.

CREATE USER app_user WITH PASSWORD '••••••';
GRANT CONNECT ON DATABASE app_db TO app_user;
GRANT USAGE ON SCHEMA public TO app_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_user;

Oracle

A user is a schema. A new account needs CREATE SESSION before it can even log in, then object or system privileges for data access.

CREATE USER app_user IDENTIFIED BY "••••••";
GRANT CREATE SESSION TO app_user;
GRANT SELECT ON app_db.employees TO app_user;

SQL Server

Authentication (a server-level LOGIN) is separate from authorization (a database USER). Membership in fixed roles like db_datareader is the idiomatic way to grant access.

CREATE LOGIN [app_user] WITH PASSWORD = '••••••';
USE [app_db];
CREATE USER [app_user] FOR LOGIN [app_user];
ALTER ROLE db_datareader ADD MEMBER [app_user];

IBM Db2

Db2 doesn't store passwords — it trusts the operating system (or LDAP/Kerberos). Create the OS account first, then grant it database privileges.

-- create the OS user first, then in Db2:
GRANT CONNECT ON DATABASE TO USER app_user;
GRANT SELECT ON TABLE app_db.employees TO USER app_user;

Which permissions does each preset grant?

The presets map to a real-world job. Start with the least-powerful preset that still lets the workload run.

Not every engine supports every preset natively — for example, replication is a first-class grant in MySQL and PostgreSQL but a configuration workflow in SQL Server and Oracle. The tool disables presets that don't apply to the selected engine.

Security best practices

Monitor what those users do

Creating a separate account per application isn't just a security win — it's what makes database observability possible. Once each workload connects with its own user you can attribute every query, connection and lock to a real service, spot a runaway report before it takes down production, and see exactly who is hammering the database at 3 a.m. Least-privilege users and good monitoring are two halves of the same practice.