Configure PostgreSQL with a Dedicated User
Set up a dedicated PostgreSQL user for the Entropy Data application database.
By default, most PostgreSQL installations create an initial superuser (often called postgres).
Running Entropy Data with it is fine for local development, testing, CI/CD, and databases that are
dedicated to Entropy Data anyway. Use a dedicated user on shared database servers, in production
environments with strict security policies, and where compliance requires it.
Create the User
Entropy Data runs its database migrations (Flyway) automatically at startup, with the configured application user. That user creates the schema and therefore owns it, which is all it needs to create, alter, and drop its own tables and indexes later on.
Connect as superuser and run:
-- Configure variables (adjust as needed)
\set database 'postgres'
\set username 'entropy_data'
\set password 'your-secure-password'
\c :database
CREATE USER :username WITH PASSWORD :'password';
GRANT ALL PRIVILEGES ON DATABASE :database TO :username;
GRANT ALL ON SCHEMA public TO :username;
Granting privileges on existing tables is not a substitute for owning them. In PostgreSQL, the right
to alter or drop an object is inherent in ownership and
cannot be granted, so
GRANT ALL PRIVILEGES ON ALL TABLES does not cover ALTER TABLE or DROP TABLE. This only matters
if the tables already exist, see
Switch an Existing Installation.
Install the Extensions
The first migration run installs three extensions:
CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS hstore;
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
Recommended: run the three statements above as a superuser before starting Entropy Data for the
first time. The migration then finds them in place, IF NOT EXISTS turns it into a no-op, and the
application user never needs an admin role.
Alternative: grant the admin role for the initial installation and revoke it afterwards.
-- Azure PostgreSQL:
GRANT azure_pg_admin TO :username;
-- AWS RDS:
GRANT rds_superuser TO :username;
On Azure Database for PostgreSQL Flexible Server, vector also has to be allow-listed through the
azure.extensions server parameter.
Configure Entropy Data
Update your environment variables to use the new user:
environment:
- SPRING_DATASOURCE_URL=jdbc:postgresql://your-host:5432/postgres
- SPRING_DATASOURCE_USERNAME=entropy_data
- SPRING_DATASOURCE_PASSWORD=your-secure-password
Upgrades
Migrations that ship with later Entropy Data versions run with the same application user and need no admin role. The only exception would be a release that introduces a new PostgreSQL extension. We announce that in the release notes, and you install it the same way as during the initial setup.
Switch an Existing Installation
If Entropy Data already runs with the superuser, switching to a dedicated user needs no data
migration, but the existing tables are still owned by the superuser, and ownership is what lets later
migrations run ALTER TABLE.
-
Create the dedicated user (see above)
-
Stop Entropy Data
-
Transfer ownership of the existing tables. Connect as a superuser and run:
DO $$ DECLARE obj record; BEGIN FOR obj IN SELECT tablename FROM pg_tables WHERE schemaname = 'public' LOOP EXECUTE format('ALTER TABLE public.%I OWNER TO %I', obj.tablename, 'entropy_data'); END LOOP; END $$;Indexes and sequences follow their table, so tables are all you need to transfer.
-
Update the environment variables and start Entropy Data
Without step 3, everything keeps working until the next version upgrade, which then fails with
ERROR: must be owner of table ... while applying its migrations.
REASSIGN OWNED BY postgres TO entropy_data; is the shorter route, but it only works if postgres
is an ordinary role, such as the master user of a managed service. On a self-managed installation,
where postgres is the bootstrap superuser, it fails with cannot reassign ownership of objects owned by role postgres because they are required by the database system. The loop above works in
both cases.
Optional: Separate Migration User
To keep the runtime user from being able to change the schema at all, let Flyway migrate with its own user. Create a second user that owns the schema:
\set migration_username 'entropy_data_migration'
CREATE USER :migration_username WITH PASSWORD 'your-secure-migration-password';
GRANT ALL PRIVILEGES ON DATABASE :database TO :migration_username;
GRANT ALL ON SCHEMA public TO :migration_username;
-- the runtime user only needs to look into the schema, not to create in it
REVOKE ALL ON SCHEMA public FROM :username;
GRANT USAGE ON SCHEMA public TO :username;
-- default privileges apply per creating role, so grant them for the migration user
ALTER DEFAULT PRIVILEGES FOR ROLE :migration_username IN SCHEMA public
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO :username;
ALTER DEFAULT PRIVILEGES FOR ROLE :migration_username IN SCHEMA public
GRANT USAGE, SELECT ON SEQUENCES TO :username;
Set this up before the first start, so that every table is created under these default privileges. Then point Flyway at the migration user:
environment:
- SPRING_DATASOURCE_URL=jdbc:postgresql://your-host:5432/postgres
- SPRING_DATASOURCE_USERNAME=entropy_data
- SPRING_DATASOURCE_PASSWORD=your-secure-password
- SPRING_FLYWAY_URL=jdbc:postgresql://your-host:5432/postgres
- SPRING_FLYWAY_USER=entropy_data_migration
- SPRING_FLYWAY_PASSWORD=your-secure-migration-password
The runtime user can then run SELECT, INSERT, UPDATE, and DELETE, while CREATE TABLE,
ALTER TABLE, and DROP TABLE are rejected.