The Supabase PostgreSQL data layer backs every Makhzon engine. Latency here amplifies into POS, inventory, marketplace and reporting at the same time, so treat it as a platform-wide incident from the first warning.
Warning at p95 query latency ≥ 350 ms, critical at ≥ 900 ms. Critical means user-visible impact: page the escalation owner.
dashboard: sim://grafana/db-layerlogs: sim://logs/db-layerowner: Data Platformrunbook: RB-DBLAYER
- Primary metric: p95 query latency (ms)
- Warning threshold: ≥ 350 ms
- Critical threshold: ≥ 900 ms
- Dashboard: sim://grafana/db-layer
- Log source: sim://logs/db-layer
- SLA: 99.95% monthly availability
- SLO: p95 query < 350ms
- External dependencies: Supabase PostgreSQL / APIs / Realtime
- Database health monitor reports p95 query latency at or above the warning threshold for two consecutive evaluation windows.
- Operators report slow screens or timeouts for the affected area.
- Open the database dashboard and compare p95 query latency, active connections and CPU against the previous hour.
- Check for long-running or blocking queries and identify the top statements by total time.
- Confirm whether connection pool saturation or a lock wait chain is present.
- Check whether a migration, index build, bulk import or report job started just before the spike.
- Correlate with Performance / RPC Monitoring to see which RPCs degraded first.
- Cancel or terminate identified runaway queries (heaviest first) and record the statement for follow-up.
- Pause non-critical background jobs: reporting rebuilds, bulk sync, reconciliation runs.
- Reduce report concurrency and stop ad-hoc exports until latency recovers.
- If pool saturation is the cause, lower per-worker pool size or scale the compute tier.
- If a specific query pattern is the cause, apply the prepared index or query fix from the owning team.
- Confirm p95 query latency has been below the warning threshold for at least 10 minutes.
- Confirm the affected business services are healthy on the dashboard.
- Confirm no alerts remain open for this component and its downstream consumers.
- Spot-check one real end-to-end operation through the affected flow.
- If a deploy caused the incident, roll back to the previous release and re-verify.
- If a configuration or threshold change caused it, restore the previous value and record why.
- Re-enable any job, feature flag or channel that was paused during mitigation, one at a time.
- First responder: NOC on duty — acknowledge within 5 minutes.
- Component owner: Data Platform.
- Escalation owner (page on critical): Data Platform On-Call.
- Escalate if the metric is still critical 15 minutes after mitigation, or if data integrity is in doubt.
- Declare a major incident if two or more critical components are alerting at the same time.
Blast radius — business services affected (60)
Identity & LoginStore / Tenant ManagementMulti-Store / Group ManagementBranch / Location ManagementStaff ManagementRoles & PermissionsProduct CatalogUnits & PacksVariantsBatch ManagementSerial Number ManagementBarcode OperationsInventory LedgerWarehouse InventoryStock TransferStocktake & AdjustmentSales / POSSales InvoicingCustomer ManagementCustomer CreditCollectionsDebt AgingCollection Follow-UpCRMLoyaltyPromotionsSupplier ManagementPurchase OrdersPurchasingSupplier AccountSupplier PaymentsSupplier GovernanceWholesale CatalogB2B Order ManagementB2B NegotiationB2B ReceivingTrade Relationship ManagementRental ManagementExpense ManagementGeneral Ledger AccountingCost CentersProfitabilityFinancial ReportingVAT ManagementZATCA E-InvoicingE-Commerce IntegrationE-Commerce Order ImportSubscription ManagementEmail NotificationPush NotificationSupport / HelpdeskSupport SLA & QualityAudit & ComplianceMonitoring & DiagnosticsSearchStore AlertsData ImportsSMS MessagingReporting & AnalyticsPlatform Administration
Supabase PostgreSQL / APIs / Realtime — Primary data plane, RPC and realtime channels
Simulated incidents that exercise this runbook
Supabase DB degradation — Primary Postgres data plane latency spike; RPC timeouts across engines.
- Record start time, actions taken and recovery time in the incident record.
- Attach the dashboard screenshot and the dominant error message to the postmortem.
- Content drafted for the monitoring demo — confirm the exact commands with the owning team before production use.