Shared Database Versus Database per Service
TradeoffStaffPrincipalUpdated
You're extracting three services from a monolith over the next two quarters. They read and write 80 tables tied together by foreign keys and cross-table transactions.
Short answer: Shared Database. Keep the shared database during the extraction and give each table a single owning service that alone may write to it.
The Two Options
A
Shared Database
B
Database per Service
Drill This: Your Pick First
The Better Pick
Option A
Shared Database
Keep the shared database during the extraction and give each table a single owning service that alone may write to it. Splitting 80 entangled tables at the same time as the code doubles the migration risk and replaces transactions with distributed workflows before the boundaries are proven. Once write ownership is clean, each service's tables can move out one at a time with change data capture (CDC).
When the Other One Wins
Database per Service
When one service has distinct scale, availability, or compliance needs, such as payment card data with its own audit scope, give it a separate database early, even mid-migration.