Data model

StackRivet’s schema follows a few firm conventions so it stays portable across MySQL and PostgreSQL and never collides inside a customer’s database. The exact, current schema is whatever the Flyway migrations define — this page is the shape they all share.

Conventions

• sr_ prefix on every table; module tables use sr_<module>_<entity> (e.g. sr_cm_customer).
• Standard columns — every core table has id, created_at, updated_at; auditable tables add created_by / updated_by; multi-tenant-ready tables carry tenant_id (default 'default'); soft-deletable tables carry deleted / deleted_at; optimistic-locked tables carry version.
• IDs are strings (VARCHAR(32)), typically a Snowflake / distributed ID.
• Enums are short strings, not a database enum type — so the schema stays portable across MySQL and PostgreSQL.
• Files are references, not URLs — a column like avatar_asset_id stores an assetId, resolved through the Asset Service.
• Both MySQL 8.4 and PostgreSQL 18.4 are supported; portable SQL lives in common/, dialect-specific SQL in mysql/ and postgresql/.

Core table groups

Group	Tables (representative)
System & RBAC	sr_sys_user, sr_sys_role, sr_sys_user_role, sr_sys_role_menu, sr_sys_menu, sr_sys_dept, sr_sys_post, sr_sys_user_post, sr_sys_dict_type, sr_sys_dict_item, sr_sys_param
Asset Service	sr_asset, sr_asset_ref
Code generator	sr_gen_table, sr_gen_column, sr_gen_file, sr_gen_history
Audit	operation / login / exception log tables
Async tasks	sr_task_instance (+ execution), result stored as an asset
Module manifest	sr_module_manifest, sr_module_permission, sr_module_menu

sr_asset_ref records which business rows reference which assets (a many-to-many relation), which is how the Asset Service stays decoupled from business tables — it never references them directly. RBAC is wired through join tables (sr_sys_user_role, sr_sys_role_menu, sr_sys_user_post), and each module ships a manifest so its menus, permissions and migrations register on startup.

Seeing the exact schema

# the migrations themselves:
ls stackrivet-<module>/src/main/resources/db/migration/

# what's actually applied (after startup):
SELECT version, description, success FROM flyway_schema_history ORDER BY installed_rank;

For an entity’s exact columns, read its migration — adding a column means adding a migration, so the migrations are always the truth.