Dual Database Apps

Build receptionist and guest-facing apps that read booking context from core while storing app workflow data safely in the app database.

Use this pattern when your app needs to communicate with guest management data in algoritmi-core while saving operational app state in algoritmi-vibe-coding.

Architecture

Use two database connections with clear responsibilities:

  • DATABASE_URL: writable app database (algoritmi-vibe-coding)
  • CORE_DATABASE_URL_RO: read-only core database (algoritmi-core)

Do not use cross-database foreign keys. Relate records by IDs (for example booking_id, property_id, room_id) in application logic.

Data Protection Rules (Required)

  1. Never write to CORE_DATABASE_URL_RO.
  2. Never copy guest PII into app tables.
  3. Store only identifiers and app-specific workflow state in app tables.
  4. Query only the minimum core fields needed for the feature.

Allowed in app database

  • booking_id, property_id, room_id, row_room_id
  • app status, timestamps, assignment data, workflow flags
  • internal operational notes that do not include guest PII

Not allowed in app database

  • first_name, last_name
  • copied guest notes from core booking records
  • full booking payload snapshots with PII

Core Tables You Will Usually Read

For receptionist and guest-facing features, these core tables are common sources:

  • public.properties (branch/property context)
  • public.rooms (room context)
  • public.bookings (booking linkage with booking_id)
  • public.room_offers_daily (availability/pricing context)
  • public.reception_notifications (front-desk notification events)

Use core tables for lookup and display context. Persist only IDs and app workflow state in your app tables.

Implementation Pattern

  1. Read booking/property/room context from core via CORE_DATABASE_URL_RO.
  2. Persist app-specific decisions and workflow state to app DB via DATABASE_URL.
  3. Rehydrate display payloads by combining app rows with current core lookup data at runtime.

This is the recommended model for flows like parking reservations, reception task queues, front-desk guest requests, and similar operational tools.

Workflow Governance (Still Required)

Even for dual-database apps, follow the standard change workflows:

  • Minor Changes: use for one-session feature additions or bug fixes.
  • Phase Development: use for multi-day features with structured phased delivery.
  • Big Changes: use for major pivots or architecture/documentation overhauls.

Quick decision cues:

  • Small focused update -> Minor Changes
  • Multiple related tasks over days/weeks -> Phase Development
  • Full restructure and docs rewrite -> Big Changes

You should also keep Workflow Overview in scope when planning delivery.

Environment and Deployment References

DATABASE_URL and CORE_DATABASE_URL_RO are deployment/runtime variables; keep names exact and consistent.