# Database Architecture

> Architecture only. Column-level reference → [database-schema.md](../reference/database-schema.md)

## Pattern

**Database-per-service** ([ADR-001](adr/ADR-001.md)).

| Service | Database |
| --- | --- |
| Core Platform | `core_platform_db` |
| Identity & Access | `identity_access_db` |
| Accounting (future) | `accounting_db` |
| CRM (future) | `crm_db` |
| Ecommerce (future) | `ecommerce_db` |
| Website Builder (future) | `website_builder_db` |
| Live Chat (future) | `live_chat_db` |
| AI Assistant (future) | `ai_assistant_db` |
| Smart Messenger (future) | `smart_messenger_db` |
| SMS Panel (future) | `sms_panel_db` |
| Link Shortener (future) | `link_shortener_db` |
| Notification (future) | `notification_db` |
| File Storage (future) | `file_storage_db` |
| Restaurant (future) | `restaurant_db` |

## Hard Rules

1. No direct queries across service databases.
2. No cross-DB foreign keys.
3. Every business table includes `tenant_id` ([ADR-003](adr/ADR-003.md)).
4. IDs are UUID; timestamps are timezone-aware.
5. Migrations via Alembic per service; never edit applied migrations in production.
6. Conceptual schemas for future services are documented in reference docs until migrations exist.

## Core Platform Ownership

Tenants, domains, plans/features/subscriptions, registries, internal tokens, outbox/inbox, audit logs, core users, operational `tenant_memberships`.

## Identity Ownership

`user_profiles`, identity-layer `tenant_memberships` (not the Core table — [ADR-007](adr/ADR-007.md)).

## Dual Membership Clarification

| Database | Table | Role |
| --- | --- | --- |
| `core_platform_db` | `tenant_memberships` | Workspace authorization source of truth |
| `identity_access_db` | `tenant_memberships` | SSO membership listing |

## Related Documents

- [Database Schema](../reference/database-schema.md)
- [Multi-Tenant Architecture](multi-tenant-architecture.md)
- [ADR-001](adr/ADR-001.md) · [ADR-007](adr/ADR-007.md)