إنتقل إلى المحتوى الرئيسي

ADR-003: Database — MariaDB

Status: Accepted Date: May 2026

Context​

BayanCore requires a reliable, ACID-compliant relational database for structured business data. The database must support ERPNext's core functionality including financial transactions, inventory management, payroll, and workflow state management.

ERPNext's Frappe framework is built primarily around MariaDB/MySQL. While PostgreSQL support exists, it is experimental and not production-ready for all ERPNext features.

Decision​

MariaDB is selected as the primary database for BayanCore.

Rationale:

  • Native ERPNext/Frappe database — fully supported and production-ready
  • Full ACID compliance for financial transactions
  • JSON support for flexible document storage
  • Window functions and CTEs (MariaDB 10.6+)
  • OCI managed MariaDB service available
  • Zero compatibility risk with ERPNext upgrades
  • Proven at scale in thousands of ERPNext deployments

Deployment Configuration:

  • OCI managed MariaDB service in Riyadh region
  • Multi-AZ high availability
  • Automated daily backups with point-in-time recovery
  • Read replicas for reporting and analytics workloads

Note on Vector Search:

Since MariaDB does not support vector embeddings natively, vector search for the AI RAG pipeline is handled by a separate service (see ADR-008: OCI Search with OpenSearch).

Consequences​

  • Positive: Native ERPNext compatibility, proven reliability, zero upgrade risk, managed service available
  • Trade-offs: Weaker JSON capabilities compared to PostgreSQL, no native vector support (requires separate vector DB)
  • Risks: Single point of failure without proper HA setup, MariaDB ecosystem smaller than PostgreSQL

Alternatives Considered​

  • PostgreSQL: Better JSONB and native vector support (pgvector), but ERPNext PG support is experimental — high risk for production ERP workloads
  • MongoDB: Not ACID-compliant for financial data, incompatible with ERPNext
  • Oracle DB: Higher cost, overkill for current scale, vendor lock-in
  • Dual database (MariaDB + PostgreSQL): Adds unnecessary complexity and operational overhead