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
Lead Systems Architect & Founder · KOLMOS Systems
The $100 Billion Problem: Database Protocol Silos
In modern software engineering, technology stacks are deeply coupled to their underlying database wire protocol:OP_MSG frames."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
┌─────────────────────────────────────────────────────────────────────────────┐
│ 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) │
└─────────────────────────────────────────────────────────────────────────────┘
Technical Blueprint
Storage PlaneCloudflare R2 CAS
Execution CoreDataFusion SIMD
Decode Fidelity100% Bit-Exact
Wire DoorsPG · MySQL · Mongo
Official Channels
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 andpgwire. The engine routes SQL query strings directly into Apache DataFusion's logical planning pipeline:
rust
// Simplified Postgres Query Handler in KOLMOS
pub async fn handle_pg_query(
query_str: &str,
session_ctx: &SessionContext,
) -> Result<Vec<RecordBatch>, 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:
table_name.column_name , which is automatically normalized into standard ANSI SQL double-quote identifiers for DataFusion., which the translator parses and converts into standard ANSI LIMIT count OFFSET offset. / SHOW COLUMNS 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_MSGTranslating Document Commands to Columnar Relational Plans:
& $match). & $sum) are mapped into flattened Arrow Struct arrays or extracted dynamically on query evaluation without performance overhead.
javascript
// 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
┌────────────────────┬──────────────┬─────────────┬─────────────┐ │ 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:Try KOLMOS Today
Deploy Your First Self-Compressing Store.
Connect via PostgreSQL, MySQL, or MongoDB. 10 GB free developer storage included.