Narrative Goldmine

Centralised Database

9 min read

Properties

Type
  • Class
Resource
  • urn:ngm:class:centralised-database
Domain
  • data
Status
  • stable
Maturity
  • mature
Quality
  • 0.72
Is a
Part of
Has part
Requires
Enables
Generated
  • by: process:vault-migrate/1.0 · at: 2026-09-22T12:41:39.024503178Z
Bridges to
Contrasts with
Depends on
Implements
Links
Page resource
  • urn:visionflow:page:7988b71a4f42f670cd1f37ba742c2d044f9ebed1709595c39d8b9b47272528dc
Related to
Standardized by
Supports
Uses

A centralised database is a data management system in which all data is stored, administered, and accessed through a single physical or logical location under a single controlling authority. It provides a unified, authoritative view of data with strong consistency guarantees, simplified access control, and a single point of administration. All read and write operations are routed to this central node or cluster, making it the canonical source of truth for the entire system. The centralised model contrasts with distributed and decentralised architectures by sacrificing geographic fault-tolerance and autonomy in exchange for consistency, reduced coordination overhead, and operational simplicity.

Overview

  • A centralised database concentrates data storage, retrieval, and administration within a single server or tightly-coupled cluster operated by a single controlling authority.
  • All client applications connect to this central point; there is one canonical representation of every record, eliminating the synchronisation complexity inherent to Distributed Systems.
  • Why it matters
    • Provides the simplest operational model for achieving ACID Properties: Atomicity, Consistency, Isolation, and Durability are enforced locally without the need for distributed coordination protocols.
    • Enables deterministic Query Optimisation because the query planner has full visibility of all data in one place.
    • Supports mature tooling for Data Governance, schema management, and reporting that has been refined over decades.
    • Regulatory regimes (GDPR, HIPAA, SOX) often assume a single data custodian, making centralised control easier to audit and certify.
  • How it works
    • Clients issue queries — typically in SQL — to a single endpoint.
    • The Query Engine parses, optimises, and executes the query against a unified storage layer.
    • Transaction Management ensures that concurrent operations respect isolation levels and atomicity boundaries.
    • Indexing structures (B-trees, hash indexes, covering indexes) accelerate read performance.
    • Replication to standby replicas may be used for read-scalability and warm failover, but the primary node remains the single write authority.
    • Backup and Recovery processes snapshot the central store on a schedule and ship write-ahead logs to secondary locations.

Key Components

  • Storage Engine — manages the physical layout of data on disk or SSD; examples include InnoDB (MySQL), nbtree (PostgreSQL), and WiredTiger (MongoDB). Related to Data Storage.
  • Query Engine — parses SQL or equivalent query language, constructs execution plans, and returns result sets. See Query Optimisation.
  • Transaction Manager — enforces ACID Transactions using locking, multi-version concurrency control (MVCC), or optimistic concurrency strategies. See Transaction Management.
  • Buffer Pool / Cache — holds frequently accessed pages in memory to reduce disk I/O latency. Central to Query Optimisation.
  • Access Control Module — enforces Centralised Access Control via role-based or attribute-based permissions. Feeds into Data Governance.
  • Replication Subsystem — streams write-ahead log (WAL) or binlog events to standby replicas; supports Replication for high availability and read scaling.
  • Backup and Recovery Engine — produces full and incremental backups; enables point-in-time recovery. Related to Backup and Recovery.
  • Audit Logger — records all data access and modification events for compliance. Underpins Audit Logging and Regulatory Compliance.
  • Schema Catalogue / Data Dictionary — stores metadata about tables, columns, constraints, indexes, and relationships. Part of Data Management.
  • Network Interface / Connection Pool — manages client connections over TCP/IP, reducing connection overhead for high-concurrency workloads. Requires Network Infrastructure.

Mechanisms

  • ACID Properties — all transactions satisfy Atomicity (all-or-nothing), Consistency (valid state transitions), Isolation (concurrent transactions do not corrupt each other), and Durability (committed data survives crashes). See ACID Properties and ACID Transactions.
  • MVCC (Multi-Version Concurrency Control) — maintains multiple row versions so readers do not block writers; used in PostgreSQL, Oracle, and MySQL InnoDB. Supports high read concurrency without locking.
  • Write-Ahead Logging (WAL) — changes are first written to a sequential log before being applied to data pages, enabling crash recovery and streaming Replication.
  • Index Structures — B-tree, hash, GIN, and GiST indexes stored centrally allow the Query Engine to satisfy predicates without full-table scans. See Indexing.
  • Lock Management — row-level, page-level, or table-level locks coordinate concurrent writes; deadlock detection resolves cycles automatically.
  • Query Planning — the optimiser uses centralised statistics (row counts, selectivity estimates) to choose join orders and access paths. See Query Optimisation.
  • Partitioning — large tables may be horizontally or vertically partitioned within the central server to improve manageability without distributing authority.

Applications and Use Cases

  • Enterprise Resource Planning (ERP) — systems such as SAP and Oracle EBS rely on a centralised database as the single source of truth for financial, HR, and supply-chain records.
  • Banking and Financial Services — core banking platforms require strict ACID Properties and a single authoritative ledger; centralised RDBMS (Oracle DB, IBM Db2) dominate. See Finance.
  • Healthcare Record Systems — electronic health record (EHR) platforms centralise patient data to enforce Regulatory Compliance with HIPAA and equivalent standards.
  • Government and Public Sector — tax authorities, land registries, and identity systems store records in tightly controlled centralised stores. Connects to Data Governance.
  • E-commerce Platforms — product catalogues, inventory, and order management typically run on centralised RDBMS before sharding becomes necessary at extreme scale.
  • Content Management Systems (CMS) — WordPress, Drupal, and similar platforms persist all content in a single Relational Database (commonly MySQL or PostgreSQL).
  • Operational Data Stores (ODS) — real-time integration layers that aggregate transactional data from multiple source systems into one queryable store. Related to Data Warehouse.
  • Machine Learning Feature Stores — centralised databases (often NoSQL Database or in-memory RDBMS) serve pre-computed features to ML inference pipelines. Bridges to Federated Learning when privacy requirements demand data partitioning.
  • IoT Data Ingestion (edge-to-cloud) — sensor streams are consolidated into a central time-series database for analytics and dashboarding. Related to Cloud Storage and Data Lake.

Contrasts and Trade-offs

  • vs Distributed Database — a distributed database partitions data and query processing across multiple nodes, sacrificing some consistency (or requiring expensive coordination) to achieve horizontal scalability and geographic redundancy. The centralised model foregoes this at the cost of a Single Point of Failure.
  • vs Decentralised Storage — decentralised storage (e.g. IPFS, Filecoin) distributes both data and administrative control, removing the need for a trusted central authority. This aligns with Blockchain philosophy where no single party controls the canonical state.
  • CAP Theorem framing — under network partition, a centralised database typically prioritises Consistency and Availability (CP or CA) because the partition is usually within a data-centre boundary rather than across independent operators.
  • vs Federated Learning — when data cannot be centralised for privacy or regulatory reasons, Federated Learning trains models locally and shares only gradients, bridging the gap without centralising raw data.

Standards and Governance Context

  • IEC 9075 (SQL Standard) — defines the SQL query language implemented by virtually all centralised relational database engines; current edition is SQL:2023.
  • ANSI SQL — the American National Standards Institute version of the SQL standard, historically the baseline for portability.
  • GDPR (General Data Protection Regulation) — mandates that personal data controllers identify a single point of accountability, a requirement that centralised databases satisfy naturally. Relates to Regulatory Compliance and Data Governance.
  • SOC 2 / ISO 27001 — information security standards that require demonstrable access control and audit trails; centralised databases simplify Audit Logging evidence collection.
  • HIPAA (Health Insurance Portability and Accountability Act) — US healthcare data regulation requiring strict data custodianship; centralised databases are the conventional compliance vehicle.
  • Common implementations — PostgreSQL, MySQL, Oracle Database, Microsoft SQL Server, IBM Db2, SQLite; these are the dominant centralised RDBMS products in use worldwide.
  • NoSQL Database variants — MongoDB, Redis, Cassandra can also operate in a centralised single-primary mode, extending the centralised model beyond relational schemas.

Current Landscape (2026)

  • The classic single-node centralised store is being pushed toward “regionless” and geo-fenced designs: Gartner estimates that by 2025 around 75% of enterprise-generated data is created and processed outside traditional centralised data centres, and Mordor Intelligence attributes roughly +1.7% of forecast CAGR to regionless architectures answering sovereignty laws.
  • Data-sovereignty regulation is the dominant 2025–2026 force reshaping where centralised data may sit: the EU Data Act became fully applicable on 12 September 2025 (mandating portability and banning lock-in), the EU published its Cloud Sovereignty Framework in October 2025 with an eight-requirement sovereignty score, and the EU AI Act reaches full enforcement in August 2026.
  • PostgreSQL has consolidated as the default relational engine underpinning modern centralised and DBaaS deployments, hitting ~55.6% adoption in the 2025 Stack Overflow survey; PostgreSQL 18 shipped in late 2025 with a new asynchronous I/O subsystem, skip scans and UUIDv7.
  • A 1bn (rebranded Lakebase), Snowflake bought Crunchy Data for ~$250m (Snowflake Postgres, public preview December 2025), and Microsoft launched HorizonDB (previewed at Ignite, November 2025).
  • Horizontal scale-out to escape single-node limits intensified in 2025 with three competing distributed-Postgres sharding projects — Supabase’s Multigres, PlanetScale’s Neki and the PgDog pooler — alongside AWS Aurora DSQL and Google AlloyDB.
  • AI-native integration became baseline: vector search is now standard in mainstream databases, and 2025 saw near-universal adoption of Anthropic’s Model Context Protocol (MCP) for agent access, with over 13,000 MCP servers launched on GitHub.
  • Market sizing shows continued strong growth despite the decentralisation pressure — analysts placed the cloud database / DBaaS market at roughly 28.51bn in 2026) with forecast CAGRs of ~15–20% to the early 2030s.
  • Open challenges as of 2026 centre on the residency-versus-sovereignty gap: storing data in an EU region owned by a US provider does not escape the US CLOUD Act, driving customer-managed encryption keys, EU-native open-source stacks (Trino, Iceberg, DuckDB) and a measurable move from SaaS back to self-hosted, jurisdiction-bound deployments.

References

Provenance

Graph View

Backlinks