Kolmos Logo
KOLMOS
Home/Journal/Architecture
Architecture·18 min read·August 18, 2026

Multi-Wire Protocol Architecture: Unifying PostgreSQL, MySQL, and MongoDB in Rust

How to engineer a single unified database execution plane that speaks pgwire, MySQL async protocol, and MongoDB BSON simultaneously without client SDK dependencies.

Punit Nigam
Punit Nigam
Lead Systems Architect & Founder · KOLMOS Systems
Key Architectural Takeaway

Migrating databases usually requires rewriting thousands of lines of ORM and query code. Here is the complete systems architecture of how KOLMOS accepts connections from Prisma, Django, Laravel, and Mongoose simultaneously.

The $100 Billion Problem: Database Protocol Silos


In modern software engineering, technology stacks are deeply coupled to their underlying database wire protocol: - If a team builds their application in **Next.js with Prisma** or **Python with Django**, they connect via the **PostgreSQL wire protocol**. - If a team builds with **PHP Laravel, WordPress, or Go GORM**, they frequently communicate via the **MySQL wire protocol**. - If a team builds document-heavy microservices in **Node.js with Mongoose** or **Python with PyMongo**, they serialize queries into **MongoDB BSON OP_MSG frames**.
When database operating costs surge into tens of thousands of dollars per month on legacy cloud platforms, engineering leaders face an agonizing dilemma:
*"We want to migrate to modern object-storage economics, but rewriting our ORMs, models, SQL queries, and aggregation pipelines will consume 6 to 12 months of senior engineering bandwidth."*

This guide explains the complete systems engineering architecture of how **KOLMOS** eliminates switching costs by implementing a **Multi-Wire Drop-In Architecture** in Rust, enabling standard PostgreSQL, MySQL, and MongoDB drivers to connect directly to a single unified storage plane with zero application code changes.

Section 1: The Unified System Topology


Instead of building three separate databases or running multiple heavyweight container sidecars, KOLMOS unifies wire protocols using a 4-tier stateless architecture:
text
KOLMOS Engine 
┌─────────────────────────────────────────────────────────────────────────────┐
│                       INCOMING WIRE PROTOCOL TRAFFIC                        │
├──────────────────────────────┬──────────────────────┬───────────────────────┤
│ PostgreSQL Clients (Prisma)  │ MySQL Apps (Laravel) │ MongoDB Apps (Mongoose)│
│ postgres://user:pass@...     │ mysql://user:pass@.. │ mongodb://user:pass@..│
└──────────────┬───────────────┴──────────┬───────────┴───────────┬───────────┘
               │                          │                       │
               ▼                          ▼                       ▼
┌──────────────────────────────┬──────────────────────┬───────────────────────┐
│ Door 1: pgwire (Postgres)    │ Door 2: opensrv-mysql│ Door 3: BSON OP_MSG   │
│ - SCRAM-SHA-256 Auth         │ - MySQL Handshake    │ - Document Parser     │
│ - Extended Query Protocol    │ - Dialect Translator │ - Relational Projector│
└──────────────┬───────────────┴──────────┬───────────┴───────────┬───────────┘
               │                          │                       │
               └──────────────────────────┼───────────────────────┘
                                          ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│               TIER 2: UNIFIED EXECUTION PLANE (Apache DataFusion)           │
│ - Vectorized SIMD Arrow Memory Batches                                      │
│ - Min/Max Header Statistics Pruning (~90% Segments Skipped)                 │
│ - In-Memory PK Bloom Filter Sidecars (~99% Point Lookups Pruned)            │
└─────────────────────────────────────────┬───────────────────────────────────┘
                                          ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│          TIER 3: STORAGE & DEDUPLICATION (Cloudflare R2 & AWS S3)           │
│ - FastCDC Content-Addressed Chunking (~64KB Dedup Blocks)                   │
│ - Cryptographic WASM Covenant (100% Bit-Exact Recovery)                     │
└─────────────────────────────────────────────────────────────────────────────┘


Section 2: Implementing the PostgreSQL Wire Protocol (pgwire)


PostgreSQL uses a binary protocol with distinct message frames for Startup, Authentication, Simple Query ('Q'), and Extended Query Protocol (Parse, Bind, Describe, Execute, Sync).
#

1. Session Context Integration

Incoming PostgreSQL connections are handled asynchronously using Tokio and pgwire. The engine routes SQL query strings directly into Apache DataFusion's logical planning pipeline:
rust
KOLMOS Engine 
// Simplified Postgres Query Handler in KOLMOS
pub async fn handle_pg_query(
    query_str: &str,
    session_ctx: &SessionContext,
) -> Result, KolmosError> {
    // 1. Parse AST and generate DataFusion Logical Plan
    let logical_plan = session_ctx.state().create_logical_plan(query_str).await?;
    
    // 2. Apply Physical Optimizer Rules & Zone Map Pruning
    let physical_plan = session_ctx.state().create_physical_plan(&logical_plan).await?;
    
    // 3. Execute Vectorized Stream across multi-core Rayon threadpool
    let result_batches = datafusion::physical_plan::collect(physical_plan, session_ctx.task_ctx()).await?;
    
    Ok(result_batches)
}

#

2. DDL & Transaction Semantics

- CREATE TABLE: Persists table schemas durably into the catalog metadata layer. - INSERT ... RETURNING: Returns inserted row IDs directly through pgwire protocol response frames. - BEGIN / COMMIT: Handled as honest autocommit single-statement boundaries; explicit ROLLBACK returns honest SQLSTATE Refusal (0A000), ensuring zero silent data corruption.

Section 3: Implementing the MySQL Wire Protocol


MySQL utilizes a packet format with a 4-byte header (packet_length + sequence_id) and a distinct handshake authentication sequence (Native Password or caching_sha2_password).
#

Handling MySQL Dialect Quirks:

1. **Identifier Backticks**: MySQL uses ` table_name.column_name , which is automatically normalized into standard ANSI SQL double-quote identifiers for DataFusion. 2. **Limit/Offset Syntax**: MySQL supports LIMIT offset, count, which the translator parses and converts into standard ANSI LIMIT count OFFSET offset. 3. **SHOW TABLES / SHOW COLUMNS**: Translated into internal information_schema table queries so administrative GUIs (TablePlus, DBeaver, MySQL Workbench) function seamlessly.

Section 4: Implementing the MongoDB Wire Protocol (BSON OP_MSG)


Unlike PostgreSQL and MySQL, MongoDB uses the **BSON (Binary JSON) OP_MSG** protocol framing.
#

Translating Document Commands to Columnar Relational Plans:

1. **find & $match**: Parsed into DataFusion relational filter expressions (BinaryExpr { left, op: Eq, right }). 2. **$group & $sum**: Mapped to Arrow vectorized aggregation kernels. 3. **Nested Document Flattening**: Deeply nested JSON documents (user.address.city) are mapped into flattened Arrow Struct arrays or extracted dynamically on query evaluation without performance overhead.
javascript
KOLMOS Engine 
// Standard Mongoose app connecting to KOLMOS with zero changes
import mongoose from "mongoose";
await mongoose.connect("mongodb://kolmos:secret@cloud.kolmos.dev/production");
const User = mongoose.model("User", new mongoose.Schema({
  email: String,
  totalOrders: Number,
  createdAt: Date,
}));
// Executes vectorized SIMD aggregations under the hood!
const results = await User.find({ totalOrders: { $gt: 10 } })
  .sort({ createdAt: -1 })
  .limit(20);


Section 5: Point Lookup Acceleration via In-Memory PK Bloom Sidecars


A primary critique of object-storage analytical databases has historically been **slow single-row point lookups** (WHERE id = 'uuid-...' or findById). On cloud storage, evaluating 2,000 segment headers sequentially takes ~116 ms.
#

The Three-Part Fix (Design Note 035):

1. **Rayon Parallel Evaluation**: Parallelize the segment scan loop across available CPU cores. 2. **0.1% False Positive Rate Bloom Tuning**: Each 200,000-row segment generates a lightweight **~240 KB Bloom filter sidecar**. 3. **In-Memory Sidecar Caching**: Bloom filters are content-addressed by their Blake3 derived key (ChunkHash(blake3("kolmos-pkbloom-v1" ++ segment_id))`) and cached in RAM.
text
KOLMOS Engine 
┌────────────────────┬──────────────┬─────────────┬─────────────┐
│ 10M-Row Point Scan │ Before Cache │ After Cache │ Speedup     │
├────────────────────┼──────────────┼─────────────┼─────────────┤
│ P50 Latency        │     116.0 ms │      8.8 ms │ 10.5× Faster│
└────────────────────┴──────────────┴─────────────┴─────────────┘


Section 6: Summary & Getting Started


By multiplexing **PostgreSQL, MySQL, and MongoDB wire protocol doors** over a single **Apache DataFusion vectorized execution core** and **Cloudflare R2 storage layer**, engineering teams achieve: - **Zero code rewrites** for existing ORMs and database drivers. - **85%–95% direct cloud storage savings** over AWS RDS and MongoDB Atlas. - **100% bit-exact decode fidelity** guaranteed by WebAssembly covenants.
Try KOLMOS Today

Deploy Your First Self-Compressing Store.

Connect via PostgreSQL, MySQL, or MongoDB. 10 GB free developer storage included.

Start Free Trial ⚡Inspect Architecture
Technical Blueprint
Storage PlaneCloudflare R2 CAS
Execution CoreApache DataFusion
Decode Fidelity100% Bit-Exact
Wire DoorsPG · MySQL · Mongo
Related Articles
Economics
How to Slash Cloud Database Storage Bills by 90%: The Complete Engineering Guide