Google Sign-In Required

Use your company Google account to access the BetterFleet private content.

Back to private home

BetterFleet Support Private
Skip to content
BetterFleet Dev Wiki
0005 - Data Persistence
Initializing search
    bf-dev
    • Home
    • Product Capabilities
    • Process
    • Current Work
    • System Design
    • Software Reference
    • Operations
    bf-dev
    • Home
      • Overview
      • Manage
      • Overview
      • Product Engineering Workflow
      • Product Engineering Delivery
      • Product Engineering Workflow in Linear
        • GitLab Feature Flags
        • In-App Docs Authoring
        • Release Notes
      • Templates
      • Publishing
      • Workflow Companions
      • Overview
      • Active Artifacts
      • Backlog Artifacts
      • Archived Artifacts
      • Overview
      • Microgrid
      • OSCP
        • Challenge
        • Specification
        • Spec
        • Architecture
        • Overview
        • Script Runtime Model
        • Compose Profiles and Modes
        • Repo Topology
        • CI and Release Integration
        • Overview
        • Internal Application Diagrams
          • Overview
          • Web Model
          • Core Model
        • Service Interaction Flows
        • Data and State
          • Index
          • bf-manage-web
          • bf-manage-core
          • bf-manage-connect
          • bf-manage-sitepwrmon
          • bf-manage-incidents
          • bf-telematics
          • bf-depot-sim
          • bf-manage-roaming
          • bf-support-microsite
          • bf-digital-twin
          • bf-schedule-creator
        • Overview
        • Internal Application Diagrams
        • Migration and Flags
        • Simulation Request Lifecycle
          • Index
          • bf-bnl-ui
          • bf-bnl-settings
          • bf-bnl-schedule-analysis-compute
          • bf-route-modelling
          • bf-schedule-creator
          • bf-digital-twin
        • Overview
        • Secrets and Env Strategy
        • Vendors and Local Dependencies
        • ADRs
        • Service Matrix
        • Cloud Dependencies
        • Ports and URLs
      • Onboarding
      • Daily Operations Runbook
        • Overview
        • Staging Hotfix Release
        • Production Hotfix Release
        • Terraform Plan Dry Runs
      • Troubleshooting
      • Testing Guide
    • Date
    • Status
    • Context
    • Decision
    • Consequences

    0005 - Data Persistence¶

    Date¶

    2022-09-21

    Status¶

    Accepted

    Context¶

    As the betterfleet system enlarges and becomes more complex, decisions as to how to store and persist data from multiple sources and applications must be defined. We need to align the products that we use to persist data across these mediums for a better developer experience. We have investigated various database products such as MongoDB, DynamoDB, MySQL, MariaDB, PostgreSQL and other variants of RDBs.

    Since relational and non-relational databases have vastly different use-cases and are both appropriate for particular tasks, we are willing to use both in the correct circumstances, but want to align which offering for each is best suited to our needs.

    DynamoDB is already a strong candidate for NoSQL due to its strong connection to other current infrastructure hosted in the AWS cloud.

    For relational databases, MySQL provides a less rich query language and feature offering than its more contemporary variants. PostgreSQL is a strong object-relational alternative with support for more complex data types and is more reliable to use at scale than MySQL.

    Decision¶

    We are choosing to use PostgreSQL when relation databases are appropriate. We are choosing to use DynamoDB when no-SQL databases are appropriate.

    Consequences¶

    What becomes easier or more difficult to do and any risks introduced by the change that will need to be mitigated.

    Our methods for persisting data will be standardised to use either of these two options across all software products. These are two rather well-known database products which have large support communities and tie in well with our other AWS-based infrastructure. By limiting the database products used to these two, we ease the learning curve for new developers being introduced to the system & ease development for existing contributors.

    Currently, we have other RDBs active, these will need to eventually be migrated to a postgreSQL instance. SImilarly, if there are any mongoDB or other no-sql databases active, these should be migrated to DynamoDB in the future. This introduces some devsecops overhead.

    Made with Material for MkDocs