When MariaDB-Native Features Replace—or Should Not Replace—Dedicated Data Systems

Learning outcomes

After learning temporal tables, Oracle compatibility, and federation, it is tempting to collapse every adjacent workload into MariaDB: semantic search, document search, geospatial search, historical analytics and remote data access. That can reduce infrastructure—but only if the workload, correctness model and operational envelope actually fit. This lesson produces an Architecture Decision Record (ADR) with explicit exit criteria.

1. Start from workload questions, not products

A feature being syntactically available answers “can the server express this?” Architecture requires “can it meet the SLO and correctness model at our scale with an operable failure path?”

2. Capability inventory on the target server

SELECT VERSION() AS server_version;SHOW ENGINES;SELECT PLUGIN_NAME,PLUGIN_STATUS,PLUGIN_TYPEFROM information_schema.PLUGINSORDER BY PLUGIN_TYPE,PLUGIN_NAME;-- Temporal support probe in a disposable schema:CREATE DATABASE IF NOT EXISTS advanced21_l5;CREATE TABLE advanced21_l5.temporal_probe(id INT PRIMARY KEY, value_text VARCHAR(40))  WITH SYSTEM VERSIONING;SHOW CREATE TABLE advanced21_l5.temporal_probe\G-- Vector syntax is version-gated (MariaDB 11.7+):CREATE TABLE advanced21_l5.vector_probe(  id INT PRIMARY KEY,  embedding VECTOR(3) NOT NULL,  VECTOR INDEX(embedding) DISTANCE=cosine);

If the vector DDL fails on an older target, that is a version requirement—not a reason to hide the error. Record the capability gap in the ADR.

3. Vector search: useful, but benchmark retrieval quality

INSERT INTO advanced21_l5.vector_probe VALUES(1,VEC_FromText('[1,0,0]')),(2,VEC_FromText('[0.9,0.1,0]')),(3,VEC_FromText('[0,1,0]'));SELECT id,       VEC_DISTANCE_COSINE(embedding,VEC_FromText('[1,0,0]')) AS distanceFROM advanced21_l5.vector_probeORDER BY distanceLIMIT 3;

A three-row demo proves syntax, not production relevance. For real embeddings, benchmark representative dimensionality, corpus size, ingest/update rate, memory, p95/p99 latency and—critically—retrieval quality/recall against a labeled set. MariaDB’s vector index uses approximate nearest-neighbor techniques, so architecture decisions must include quality as well as speed.

4. FULLTEXT and spatial: semantics before performance

FULLTEXT search can be excellent for transactional applications whose search semantics match MariaDB tokenization/ranking behavior. It is not automatically a replacement for a search platform offering analyzers, synonyms, faceting, complex ranking pipelines or distributed index operations. Spatial indexes similarly help only when the geometry types, predicates and coordinate assumptions match the domain.

CREATE TABLE advanced21_l5.docs( id BIGINT PRIMARY KEY, body TEXT NOT NULL, FULLTEXT KEY ft_body(body)) ENGINE=InnoDB;INSERT INTO advanced21_l5.docs VALUES(1,'replication lag incident runbook'),(2,'temporal history retention policy');SELECT id,MATCH(body) AGAINST ('replication incident') AS scoreFROM advanced21_l5.docsWHERE MATCH(body) AGAINST ('replication incident')ORDER BY score DESC;CREATE TABLE advanced21_l5.places( id BIGINT PRIMARY KEY, p POINT NOT NULL, SPATIAL INDEX sp_p(p)) ENGINE=InnoDB;SHOW CREATE TABLE advanced21_l5.places\G

5. Wrong approach: “fewer systems is always simpler”

One database reduces the number of products but may concentrate incompatible workloads: OLTP writes, large historical scans, high-dimensional vector memory, text indexing and remote network dependencies can compete for CPU, memory, I/O and maintenance windows. Conversely, adding a specialized system introduces CDC, consistency, backup, security and on-call complexity. “Simpler” must be measured across the whole lifecycle.

6. Architecture scorecard

7. Write the ADR with exit criteria

ADR-021: Search/history architecture for ServiceHubStatus: ProposedContext:  workload, dataset size, update rate, SLOs, consistency, complianceDecision:  which capability remains in MariaDB and whyEvidence:  exact MariaDB version; schema; EXPLAIN/ANALYZE; benchmark; quality testsAlternatives:  dedicated search/vector/analytics/federated-query system; application implementationRisks:  resource contention; feature limits; backup/recovery; plugin/version couplingExit criteria:  e.g. p99 > SLO under representative load for 3 windows  recall@K below product threshold  history growth exceeds restore/RTO budget  remote-source outage causes unacceptable user impactMigration path:  CDC/export/backfill method and rollback boundaryReview date / owner:  named team and trigger

Exit criteria make reversibility real. Without them, a successful prototype becomes permanent architecture even after the workload changes.

8. Cleanup and final checks

DROP DATABASE IF EXISTS advanced21_l5;

Production judgment and bridge to Chapter 22

MariaDB’s advanced features can eliminate unnecessary infrastructure when the data already belongs in the transactional system and the workload fits. They can also create hidden coupling when used to avoid an architecture decision. Chapter 22 is the production capstone: you will combine schema, security, replication/Galera, backup/PITR, performance, application integration, upgrades and these advanced-feature boundaries into one defendable MariaDB design.

Architecture decision framework: keep the feature until an exit criterion is crossed

Native features are attractive because they reduce moving parts: the same security model, backup process, transaction boundary, schema tooling, and operational team may cover the workload. That advantage is real, but it should be compared with the specialized capability being given up. The decision is strongest when it names measurable conditions that would trigger reevaluation.

• Temporal: keep system/application-time history in MariaDB while retention volume, temporal query latency, and audit threat model remain acceptable; exit when immutable evidence or independent retention is required.
• FULLTEXT: keep native text search while language analysis, ranking, highlighting, typo tolerance, faceting, and index scale satisfy product needs; exit when search relevance/operations require a specialized engine.
• Vector: keep native vector search when dimensions, corpus size, update rate, recall/latency, filtering, and operational simplicity meet measured requirements; exit when specialized ANN features or scale dominate.
• Spatial: keep spatial data near transactional entities when supported predicates/indexes and coordinate-system needs fit; exit when advanced GIS processing/ecosystem capability becomes central.
• Federation: keep remote access only while latency, consistency, credential management, pushdown, and failure ownership are acceptable; exit when data integration becomes a platform problem.

The Architecture Decision Record should include context, chosen option, rejected alternatives, assumptions, acceptance metrics, operational owner, data-protection implications, and exit criteria. Revisit it when workload shape changes rather than waiting for a crisis. “One database for everything” and “always use a specialized system” are both weak defaults; the measurable contract decides.

Also price the migration path. A feature that is adequate today may still create expensive coupling if application APIs expose MariaDB-specific semantics everywhere. Encapsulating temporal/search/federation access behind a deliberate repository or service boundary can preserve the option to move later without pretending portability is free.

Measure switching cost before the native feature becomes a hard dependency

Exit criteria are useful only if moving is still possible. Keep representative export/replay tests, document application APIs that expose native semantics, and estimate data volume plus downtime/dual-run requirements for a future move. For search/vector/spatial workloads, keep a small relevance/recall/geospatial correctness corpus that can be run against an alternative. For temporal data, define how current and historical versions would be exported with their semantics intact.

This does not mean designing to the least-common denominator. Use MariaDB-native capabilities when they are the best fit, but isolate highly specific semantics enough that the architecture can evolve. The ADR should record both the benefit of native integration today and the evidence needed to justify a specialized system later.

Authoritative references

• MariaDB Documentation — Vector Overview
• MariaDB Documentation — CREATE TABLE with Vectors
• MariaDB Documentation — System-Versioned Tables
• MariaDB Documentation — Storage Engines
• MariaDB Documentation — Spider