The platform uses a single PostgreSQL instance (database portal), but each microservice owns its own schema rather than using public. Schema changes are managed with Flyway migrations that run automatically on service start.
Schemas
| Schema | Service | Key tables |
|---|---|---|
| auth | auth-service | portal_user, portal_role, portal_user_role |
| page | page-service | portal_page, portal_site |
| asset | asset-service | portal_asset |
| webcontent | web-content-service | portal_web_content |
| portlet | portlet-service | portal_portlet |
| soap | soap-tracker-service | portal_soap_log |
| emailtemplate | email-template-service | email_template |
| email-service | email_template, email_variable_mapping, email_send_log | |
| settings | settings-service | site_configuration, ssl_configuration, cluster_node, email_configuration, sms_configuration, auth_provider |
i
Conventions: primary keys are
BIGSERIAL; created_at/updated_at are TIMESTAMPTZ DEFAULT NOW(); multilingual columns are stored as JSON; tables are schema-qualified (e.g. auth.portal_user).Connection
Inside Docker the host is postgres:5432; from the host it is localhost:54322. Default dev credentials: database portal, user portal_user. The seeded admin is admin / admin@portal.com with ROLE_ADMIN + ROLE_USER. Browse with pgAdmin at localhost:5050.
Migrations
Migration scripts live under each module at src/main/resources/db/migration/V*.sql and are applied in version order.
<module>/src/main/resources/db/migration/V1__init.sql
<module>/src/main/resources/db/migration/V2__add_table.sql!
Never edit a migration that has already been applied. Add a new
V<next>__*.sql file instead — changing applied migrations breaks Flyway's checksums.Browsing the database
In Docker, pgAdmin is available on port 5050 for inspecting schemas and data during development.
