Gui13go
/
  • About
  • Agents
  • Publications
  • GeoLayers
  • Tools
  • Gallery
  • Blogs
  • Search
Home / Gallery / Databases

Databases & Storage Engines

An architectural deep dive into database internals, storage engines, concurrency models, and distributed paradigms.

Personalities Quotes Arts Books Languages Operating Systems Protocols Databases Data Formats Facts Laws Jokes Versus Dictionary Gadgets
Core Concepts

Essential Database Internals Quick Guide

Master the fundamental computer science primitives that distinguish world-class storage engines.

B-Tree vs. LSM-Tree

B-Trees (Postgres, SQLite, InnoDB) update pages in-place on disk with O(log N) random read/write lookups. LSM-Trees (RocksDB, Cassandra, ScyllaDB) buffer writes in a sequential in-memory MemTable before flushing immutable SSTables to disk, trading read amplification for virtually unlimited sequential write speed.

Row-Store vs. Columnar

Row stores lay entire tuple attributes consecutively in 8KB disk blocks—ideal for single-row OLTP CRUD mutations. Columnar engines (DuckDB, ClickHouse) store contiguous arrays of single columns, allowing CPU SIMD vector processing to scan millions of values per cycle with extreme compression ratios (ZSTD/Gorilla).

WAL & MVCC

Write-Ahead Logging (WAL) guarantees durability by writing transaction changes to an append-only log before modifying data pages. Multi-Version Concurrency Control (MVCC) tags tuples with creation and expiration transaction IDs, guaranteeing readers never block writers and writers never block readers.

HNSW & Vector Indexing

Hierarchical Navigable Small World (HNSW) graphs construct multi-layer proximity networks reminiscent of skip lists. High-layer traversals jump across wide vector spaces before zooming into fine-grained local neighborhoods, executing k-Nearest Neighbor searches across millions of embeddings in single-digit milliseconds.

Architecture Blueprint

Database Storage Paradigms & Internals Matrix

Compare storage models, underlying data structures, concurrency guarantees, and P99 latency profiles across core database categories.

Paradigm Representative Engines Internal Storage Engine Storage Model ACID / Consistency P99 Latency Primary Sweet Spot
Relational (OLTP) PostgreSQL, MySQL, MariaDB, CockroachDB B-Tree / Heap Files / Buffer Pool Row-Oriented (Slotted Page) Full ACID (Serial / Snapshot) Sub-millisecond to ~3ms Banking, e-commerce, user accounts, transactional core
Embedded Relational SQLite, PGlite (WASM) B-Tree Pager / Flat Single-File / WASM Heap Row-Oriented Full ACID (WAL / Rollback Journal) Microsecond (< 50µs) Mobile apps, IoT, desktop apps, local-first web applications
Columnar OLAP DuckDB, ClickHouse, Apache Pinot, Apache Druid Vectorized SIMD / MergeTree / Star-Tree Column-Oriented (Compressed Chunks) Optimistic / Immutable Segments 10ms - 100ms on millions/billions of rows Ad-hoc BI, telemetry, Parquet analytics, clickstream, real-time dashboards
Key-Value / Memory Redis, Memcached, RocksDB, LMDB In-Memory Hash / SkipLists / LSM-tree / mmap() B+ Tree Key-Value / Flat Byte Arrays / Slabs Atomic ops / WAL / Copy-on-Write Microsecond (5µs - 500µs) High-speed caching, rate limiting, session storage, storage engine primitives
Document & NoSQL MongoDB, Apache CouchDB, SurrealDB WiredTiger B-Tree / Append-only B-Tree / RocksDB BSON / JSON Document Stores / Multi-Model Document-level atomic to full Multi-Table ACID 1ms - 5ms Dynamic content schemas, mobile sync, polymorphic catalogs, edge sync
Distributed / Wide-Column Apache Cassandra, ScyllaDB LSM-Tree + MemTable + SSTables + CommitLog Wide-Column / Partition + Clustering Keys BASE / Tunable Consistency (AP) Sub-millisecond writes, linear scale High-volume writes, IoT time-series, global audit trails, ad tech
Graph Databases Neo4j, Memgraph Index-Free Adjacency / In-Memory C++ Pointers Labeled Property Graph (Nodes + Edges + Props) Full ACID (Snapshot Isolation) 1ms - 10ms for multi-hop path traversal Fraud detection rings, social networks, knowledge graphs, identity graph
Vector & Search Qdrant, Milvus, ChromaDB, Elasticsearch, Meilisearch HNSW Graphs / IVF-PQ / Lucene Inverted Index High-Dimensional Vectors + Payloads / Inverted Index WAL Segments / Eventual Consistency 1ms - 15ms ANN / BM25 search Semantic search, LLM RAG pipelines, multimodal AI, typo-tolerant search
Showing 30 of 30 databases
PostgreSQL architecture blueprint
Relational / ORDBMS

PostgreSQL

1996
Pioneered by: Michael Stonebraker & PostgreSQL Global Development Group

PostgreSQL is an enterprise-class, open-source object-relational database system with more than 35 years of active development. Known as the 'Linux of Databases', Postgres is famed for rock-solid data integrity, extensibility (foreign data wrappers, custom data types, PostGIS, pgvector), and full ACID compliance. It handles complex analytical queries, transactional workloads, and JSON document structures with equal mastery.

Storage Engine:Heap Files (append-only MVCC) + Buffer Pool
Storage Model:Row-Oriented
Query Interface:SQL (ANSI compliant) + PL/pgSQL
Concurrency:MVCC (Snapshot Isolation & SSI)
ACID & Consistency:Full ACID (Snapshot Isolation, Serializable SSI via SIREAD locks)
P99 Latency Profile:< 1ms OLTP point reads | 5-50ms analytical aggregate
Architectural Highlights & Internals:
  • MVCC Architecture: Multi-Version Concurrency Control prevents read-write blocking by retaining row versions during transactions.
  • Unmatched Extensibility: Pluggable procedural languages, custom index types (B-Tree, Hash, GiST, SP-GiST, GIN, BRIN), and extensions like PostGIS and pgvector.
  • Reliable Write-Ahead Logging (WAL): Guarantees zero data loss with point-in-time recovery (PITR) and synchronous/asynchronous streaming replication.
  • Native Hybrid Semi-Structured Data: Fast binary JSON processing via JSONB with GIN indexing for document queries.
PGVector & JSONB Hybrid Query
-- Enable pgvector extension
CREATE EXTENSION IF NOT EXISTS vector;

-- Query hybrid relational, JSONB, and semantic vector embeddings
SELECT 
    p.id, 
    p.metadata->>'title' AS article_title,
    1 - (p.embedding <=> '[0.021, -0.043, 0.812]'::vector) AS cosine_similarity
FROM documents p
WHERE p.metadata @> '{"status": "published"}'
ORDER BY p.embedding <=> '[0.021, -0.043, 0.812]'::vector
LIMIT 5;
Sweet Spot: System-of-record OLTP, complex relational joins, enterprise apps, hybrid JSON/vector workloads
Superpowers:
  • + Battle-tested rock-solid data integrity with 35+ years of production hardening
  • + World-class extensibility (pgvector, PostGIS, TimescaleDB, Citus, custom data types)
  • + Native rich JSONB support with GIN index queries matching document DB speeds
Architectural Constraints:
  • - Process-per-connection model requires connection poolers (PgBouncer) for >1000 clients
  • - Table bloat requires active VACUUM tuning due to append-only MVCC dead-tuples
Official Docs & Spec
SQLite architecture blueprint
Embedded Relational (OLTP)

SQLite

2000
Pioneered by: D. Richard Hipp

SQLite is a C-language library that implements a small, fast, self-contained, high-reliability, full-featured SQL database engine. Unlike client-server databases, SQLite does not run as a standalone background process; instead, it compiles directly into host applications and stores the entire database in a single cross-platform disk file. It is the most widely deployed database engine on Earth, running on billions of smartphones, browsers, IoT devices, and operating systems.

Storage Engine:B-Tree on Flat File / Pager Architecture
Storage Model:Row-Oriented
Query Interface:SQL
Concurrency:Single-Writer / Multiple-Readers (WAL mode)
ACID & Consistency:Full ACID (Atomic commit via rollback journal or Write-Ahead Log)
P99 Latency Profile:< 50 microseconds in-process disk read | ~1 microsecond in-memory
Architectural Highlights & Internals:
  • Zero-Configuration & Serverless: No server process to install, configure, manage, or restart. Simply open a file path and query.
  • Single-File Portability: The entire database (schema, data, tables, indexes) is stored in a single standard cross-platform binary file.
  • WAL Mode Performance: Write-Ahead Logging allows concurrent readers to operate without blocking writes and vice versa.
  • 100% Branch Test Coverage: One of the most rigorously tested software libraries in computing history.
High-Performance WAL Mode & Pragmas
-- Optimize SQLite for high-throughput concurrent reads and writes
PRAGMA journal_mode = WAL;          -- Enable Write-Ahead Logging
PRAGMA synchronous = NORMAL;        -- Safe durability with 10x write speedup
PRAGMA cache_size = -64000;         -- 64MB page cache in RAM
PRAGMA temp_store = MEMORY;         -- Store temp tables & indexes in RAM

-- Query with full window functions & CTEs
WITH RECURSIVE Fibonacci(n, a, b) AS (
    VALUES(1, 0, 1)
    UNION ALL
    SELECT n + 1, b, a + b FROM Fibonacci WHERE n < 10
)
SELECT n, a AS value FROM Fibonacci;
Sweet Spot: Mobile apps (iOS/Android), desktop software, IoT devices, local-first web apps, edge SQLite
Superpowers:
  • + Zero administration, zero background daemon, embeds directly into binary
  • + Extremely small binary footprint (< 1MB) with 100% branch test coverage
  • + Cross-platform single-file container (usable as application file format)
Architectural Constraints:
  • - Single-writer concurrency limit (WAL mode allows concurrent readers, but only 1 writer)
  • - No client-server security model or user permission access controls
Official Docs & Spec
DuckDB architecture blueprint
Embedded Analytical (OLAP)

DuckDB

2019
Pioneered by: Hannes Mühleisen & Mark Raasveldt (CWI Amsterdam)

DuckDB is an in-process SQL OLAP database management system often dubbed 'the SQLite for Analytics'. Designed for analytical query processing, DuckDB processes tabular data column by column using state-of-the-art vectorized SIMD query execution. It embeds seamlessly into Python, R, Node.js, and WASM runtimes, querying gigabytes of Parquet, CSV, and Arrow files with lightning speed without requiring a remote database server.

Storage Engine:Columnar Vectorized Execution Engine
Storage Model:Columnar
Query Interface:SQL (PostgreSQL-dialect extensions)
Concurrency:Multi-Version Concurrency Control (MVCC)
ACID & Consistency:Full ACID (Multi-Version Concurrency Control with optimistic serializable)
P99 Latency Profile:< 5ms for aggregations across millions of rows
Architectural Highlights & Internals:
  • Vectorized SIMD Execution Engine: Executes query kernels in CPU cache on vector arrays of data, unlocking blistering analytical throughput.
  • Direct Zero-Copy File Querying: Directly queries remote or local Parquet, Arrow, CSV, and JSON files without prior ingestion.
  • Zero External Dependencies: Clean C++11 single-file amalgamations that embed anywhere from a Lambda function to a browser tab via WebAssembly.
  • Advanced Analytic SQL: Supports ASOF joins, window functions, regex, recursive CTEs, and automatic query parallelization across CPU cores.
Vectorized Parquet & S3 Analytics
-- Directly query multi-gigabyte remote Parquet files with zero ingestion
SELECT 
    vendor_id,
    date_trunc('month', pickup_datetime) AS pickup_month,
    count(*) AS total_rides,
    quantile_cont(fare_amount, [0.5, 0.95, 0.99]) AS fare_percentiles
FROM 's3://yellow-taxi/year=2024/*.parquet'
WHERE passenger_count > 0
GROUP BY ALL
ORDER BY total_rides DESC
LIMIT 10;
Sweet Spot: Data science, interactive BI dashboards, ad-hoc analytics, local Parquet/Arrow exploration
Superpowers:
  • + SIMD-accelerated vectorized columnar execution on CPU L1/L2/L3 cache
  • + Queries remote or local Parquet, S3, Arrow, and CSV files with zero ingestion
  • + Seamless zero-copy integration with Python Polars, Pandas, and Apache Arrow
Architectural Constraints:
  • - Optimized strictly for batch OLAP analytics; not designed for heavy concurrent row writes (OLTP)
  • - Single-process write lock on DuckDB persistent storage file
Official Docs & Spec
IndexedDB architecture blueprint
Browser Client-Side NoSQL

IndexedDB

2015
Pioneered by: W3C Web Applications Working Group (Nikunj Mehta et al.)

IndexedDB is a low-level browser API for client-side storage of significant amounts of structured data, including files and blobs. Unlike localStorage (which is synchronous, string-only, and capped at ~5MB), IndexedDB operates asynchronously, provides ACID transactional guarantees, allows indexes for high-performance searches, and can store gigabytes of offline application state right inside Chrome, Firefox, Safari, and Edge.

Storage Engine:Browser Host Native (LevelDB / SQLite under the hood)
Storage Model:Object Store Key-Path
Query Interface:JavaScript Event-Driven Asynchronous API
Concurrency:Transaction-Based (Read-Only / Read-Write locks)
ACID & Consistency:ACID transactional scopes (readwrite and readonly transaction modes)
P99 Latency Profile:1-10ms asynchronous transactional browser disk read/write
Architectural Highlights & Internals:
  • Structured Object Stores: Stores native JavaScript objects, Blobs, ArrayBuffers, and JSON records without serialization overhead.
  • Asynchronous & Non-Blocking: DOM rendering and UI threads are never blocked during intensive disk I/O.
  • Compound Secondary Indexes: Index multiple object properties to enable range queries, cursors, and exact-match searches.
  • Offline-First Web Foundation: Essential architectural backbone for Progressive Web Apps (PWAs), offline caching, and local-first software.
Async Modern IndexedDB Transaction
// Open database with typed object store and secondary index
const request = indexedDB.open('OfflineAppDB', 2);

request.onupgradeneeded = (event) => {
  const db = event.target.result;
  const store = db.createObjectStore('documents', { keyPath: 'id' });
  store.createIndex('by_author', 'author', { unique: false });
  store.createIndex('by_created', 'createdAt', { unique: false });
};

request.onsuccess = (event) => {
  const db = event.target.result;
  const tx = db.transaction(['documents'], 'readwrite');
  const store = tx.objectStore('documents');
  
  store.put({ id: 'doc-404', author: 'guigo', title: 'DB Internals', createdAt: Date.now() });
  tx.oncomplete = () => console.log('Transaction committed safely to local disk!');
};
Sweet Spot: Offline-first web applications, Progressive Web Apps (PWAs), client-side state caching
Superpowers:
  • + Native browser standard supported across 100% of modern desktop & mobile browsers
  • + Stores structured JS objects, Blobs, ArrayBuffers, and files without manual stringification
  • + Supports secondary compound indexes and bidirectional cursor iterations
Architectural Constraints:
  • - Low-level verbose event-driven callback API (typically wrapped with idb or Dexie.js)
  • - Browser storage quotas subject to user disk eviction under OS storage pressure
Official Docs & Spec
Redis architecture blueprint
In-Memory Key-Value / Data Structures

Redis

2009
Pioneered by: Salvatore Sanfilippo (antirez)

Redis (Remote Dictionary Server) is an open-source, in-memory data store used by millions of developers as a cache, message broker, streaming engine, and database. By keeping all primary data in RAM and executing operations on native data structures (Strings, Hashes, Lists, Sets, Sorted Sets, Bitmaps, HyperLogLogs, Geospatial indexes), Redis routinely serves millions of requests per second with sub-millisecond latencies.

Storage Engine:In-Memory Hash Table + SkipLists + Radix Trees
Storage Model:RAM-first In-Memory
Query Interface:Command Protocol (RESP) + Lua Scripts
Concurrency:Single-Threaded Event Loop (Multiplexed I/O)
ACID & Consistency:Transactions via MULTI/EXEC (atomic execution, no rollbacks on logic error)
P99 Latency Profile:< 500 microseconds sub-millisecond P99 in-memory latency
Architectural Highlights & Internals:
  • Sub-Millisecond In-Memory Speed: Direct RAM lookups execute without disk seek penalties, serving P99 latencies under 1 millisecond.
  • Rich Native Data Structures: Manipulate complex arrays, sorted rankings, sets, and geospatial coordinates atomically.
  • Configurable Persistence: Balances speed and durability via point-in-time snapshots (RDB) and append-only write logs (AOF).
  • Pub/Sub & Streams: Real-time message broadcasting, consumer groups, and high-throughput event sourcing pipelines.
Redis Atomic Token Bucket Rate Limiter
# Atomic token-bucket rate limiter via Redis script or pipeline
# Key: rate_limit:user:123 (Expires after 60 seconds)
MULTI
INCR rate_limit:user:123
EXPIRE rate_limit:user:123 60
EXEC

# Query high-scores leaderboard with O(log(N)) ranking
ZADD leaderboard:weekly 14850 "player_alpha" 19200 "player_beta"
ZREVRANGEBYSCORE leaderboard:weekly +inf -inf WITHSCORES LIMIT 0 5
Sweet Spot: Ultra-fast distributed caching, session store, pub/sub messaging, sorted leaderboards, rate limiting
Superpowers:
  • + Blistering speed: serves >100,000 operations/sec per CPU core in memory
  • + Rich expressive data structures: Strings, Hashes, Lists, Sets, Sorted Sets, HyperLogLogs, Bitmaps
  • + Configurable persistence options: RDB snapshots and append-only file (AOF) logs
Architectural Constraints:
  • - Dataset size strictly limited by physical server RAM capacity
  • - In-memory primary model requires careful TTL evictions to avoid memory exhaustion
Official Docs & Spec
ClickHouse architecture blueprint
Columnar OLAP Data Warehouse

ClickHouse

2016
Pioneered by: Alexey Milovidov & Yandex

ClickHouse is a fast, open-source column-oriented database management system that allows generating analytical data reports in real time using SQL queries. Designed to ingest trillions of rows and petabytes of data, ClickHouse stores columns contiguously on disk with heavy compression, reading only the exact bytes requested by queries and delivering answers up to 100-1000x faster than traditional row-oriented databases.

Storage Engine:MergeTree Engine Family (Sparse Indexes)
Storage Model:Columnar Compressed
Query Interface:SQL (Extended ClickHouse SQL)
Concurrency:Massive Parallel Processing (MPP) / Vectorized
ACID & Consistency:Eventual consistency across shards; atomic partition and block inserts
P99 Latency Profile:10-50ms analytical queries across billions of rows
Architectural Highlights & Internals:
  • Blistering Analytical Performance: Vectorized query evaluation combined with SIMD instructions delivers billions of processed rows per second per server.
  • MergeTree Engine Architecture: Appends data in sorted parts and merges them in the background, utilizing primary key sparse indexes.
  • Extreme Data Compression: Specialized columnar codecs (DoubleDelta, Gorilla, T64, ZSTD, LZ4) shrink storage footprints by 70-90%.
  • Linear Distributed Scalability: Shards and replicates tables across thousands of nodes for petabyte-scale real-time telemetry and ad-tech analytics.
ClickHouse Real-Time Clickstream Aggregation
-- High-performance MergeTree table with ZSTD compression
CREATE TABLE clickstream_events (
    timestamp DateTime64(3, 'UTC') CODEC(DoubleDelta, LZ4),
    user_id UUID,
    event_type LowCardinality(String),
    payload_bytes UInt32 CODEC(T64, ZSTD(3))
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(timestamp)
ORDER BY (event_type, timestamp, user_id);

-- Sub-second query scanning 50,000,000 rows
SELECT 
    event_type, 
    count() AS total_events, 
    uniqExact(user_id) AS unique_visitors
FROM clickstream_events
WHERE timestamp >= now() - INTERVAL 1 HOUR
GROUP BY event_type;
Sweet Spot: Real-time web analytics, telemetry, clickstream logging, ad-tech, financial time-series
Superpowers:
  • + World-class compression algorithms (LZ4, ZSTD, Delta, DoubleDelta, Gorilla, T64)
  • + Vectorized SIMD processing capable of scanning 100+ million rows/sec per CPU core
  • + Specialized MergeTree storage engines (SummingMergeTree, ReplacingMergeTree, AggregatingMergeTree)
Architectural Constraints:
  • - Does not support granular single-row UPDATE/DELETE transactions efficiently
  • - Requires batch inserts (1,000+ rows per block) to avoid small-part fragmentation
Official Docs & Spec
MongoDB architecture blueprint
Document Store (NoSQL)

MongoDB

2009
Pioneered by: Dwight Merriman, Eliot Horowitz, Kevin Ryan (10gen)

MongoDB is a leading non-relational document database designed for modern application development. By replacing fixed tabular rows with flexible, nested BSON documents, MongoDB allows developers to model real-world hierarchical entities naturally without tedious relational join tables. It features horizontal scale-out via automatic sharding, multi-document ACID transactions, and expressive aggregation pipelines.

Storage Engine:WiredTiger (B-Tree & Cache-First)
Storage Model:BSON (Binary JSON) Documents
Query Interface:MQL (MongoDB Query Language) & Aggregation Pipeline
Concurrency:WiredTiger Document-Level Concurrency
ACID & Consistency:ACID transactions (Single-document atomic; multi-document ACID transactions supported)
P99 Latency Profile:1-5ms point document reads and writes
Architectural Highlights & Internals:
  • Dynamic Polymorphic Schema: Documents within the same collection can have divergent fields, adapting gracefully to rapid agile iterations.
  • Rich Aggregation Framework: Multi-stage data processing pipeline for filtering, grouping, reshaping, unwinding, and statistical transformations.
  • Automatic Sharding & High Availability: Replica sets provide automated failover, while sharded clusters distribute reads/writes across geographic clusters.
  • Multi-Document ACID Transactions: Guarantees consistency across multiple collections and shards without sacrificing document ergonomics.
Aggregation Pipeline with Facets
// Multi-stage document aggregation pipeline
db.orders.aggregate([
  { $match: { status: "completed", orderDate: { $gte: ISODate("2026-01-01") } } },
  { $unwind: "$items" },
  { $group: {
      _id: "$items.category",
      totalRevenue: { $sum: { $multiply: ["$items.price", "$items.quantity"] } },
      averageQuantity: { $avg: "$items.quantity" },
      uniqueBuyers: { $addToSet: "$customerId" }
  }},
  { $project: {
      category: "$_id",
      totalRevenue: 1,
      buyerCount: { $size: "$uniqueBuyers" }
  }},
  { $sort: { totalRevenue: -1 } }
]);
Sweet Spot: Dynamic content catalogs, mobile backends, polymorphic document stores, rapid MVP prototyping
Superpowers:
  • + Schema-flexible BSON document model allows seamless iteration without ALTER TABLE migrations
  • + Powerful Aggregation Pipeline framework for multifaceted data reshaping and joins ($lookup)
  • + Built-in horizontal sharding based on range or hashed shard keys
Architectural Constraints:
  • - High RAM and disk footprint compared to normalized relational engines
  • - Uncontrolled schema drift without strict JSON Schema validation rules
Official Docs & Spec
Apache Cassandra architecture blueprint
Distributed Wide-Column / Multi-Master

Apache Cassandra

2008
Pioneered by: Avinash Lakshman & Prashant Malik (Facebook)

Apache Cassandra is a distributed, wide-column store designed to handle large amounts of data across many commodity servers, providing high availability with no single point of failure. Born at Facebook to power inbox search, Cassandra blends Amazon Dynamo's peer-to-peer ring architecture with Google Bigtable's column-family data model to achieve linear write scalability across multi-datacenter clusters.

Storage Engine:LSM-Tree (Log-Structured Merge-Tree) on SSTables
Storage Model:Wide-Column Family / Key-Partitioned
Query Interface:CQL (Cassandra Query Language)
Concurrency:Tunable Eventual Consistency (CAP AP model)
ACID & Consistency:BASE / Tunable Consistency (CAP Theorem AP: ONE, QUORUM, LOCAL_QUORUM, ALL)
P99 Latency Profile:1-5ms sub-millisecond writes at linear horizontal scale
Architectural Highlights & Internals:
  • Masterless Peer-to-Peer Ring: Every node is identical; there is no master node, eliminating single points of failure and bottleneck routers.
  • LSM-Tree Write Performance: Writes are appended sequentially to commit logs and in-memory Memtables, offering unbelievable write throughput.
  • Tunable Consistency: Developers select exact consistency levels (ONE, QUORUM, LOCAL_QUORUM, ALL) per individual read or write operation.
  • Active-Active Multi-Datacenter Replication: Replicates data synchronously or asynchronously across geographic cloud regions without downtime.
CQL Time-Series Schema with Clustering Keys
-- Cassandra table partitioned across cluster nodes by sensor_id
CREATE TABLE sensor_telemetry (
    sensor_id uuid,
    bucket_date text,
    reading_time timestamp,
    temperature double,
    humidity double,
    PRIMARY KEY ((sensor_id, bucket_date), reading_time)
) WITH CLUSTERING ORDER BY (reading_time DESC);

-- Tunable consistency query across the distributed ring
SELECT reading_time, temperature, humidity 
FROM sensor_telemetry 
WHERE sensor_id = 7a8f9c10-3d84-4e31-8933-4df45e7e1634 
  AND bucket_date = '2026-10-10' 
  AND reading_time >= '2026-10-10 12:00:00'
ORDER BY reading_time DESC 
LIMIT 100;
Sweet Spot: High-volume write-heavy workloads, IoT sensor streaming, messaging, global audit trails
Superpowers:
  • + Masterless peer-to-peer architecture eliminates single points of failure (100% uptime)
  • + Append-only commit log and SSTable LSM-tree writes deliver virtually unlimited write throughput
  • + Tunable consistency allows tuning trade-offs between consistency and latency per query
Architectural Constraints:
  • - Data must be modeled strictly around query access patterns (no JOINs, no ad-hoc filtering)
  • - JVM garbage collection and tombstone purges require ongoing cluster maintenance
Official Docs & Spec
MySQL architecture blueprint
Relational DBMS (OLTP)

MySQL

1995
Pioneered by: Michael Monty Widenius, David Axmark, Allan Larsson

MySQL is the world's most popular open-source relational database management system, serving as the critical persistence layer for LAMP stacks, WordPress, Facebook, Twitter, and Netflix. Anchored by the InnoDB storage engine, MySQL provides ACID transactions, foreign keys, row-level locking, and proven durability under massive web concurrency.

Storage Engine:InnoDB (Pluggable: MyISAM, Memory, RocksDB)
Storage Model:Row-Oriented (Clustered B+Tree Index)
Query Interface:SQL
Concurrency:Row-Level Locking & Two-Phase Locking (2PL)
ACID & Consistency:Full ACID (InnoDB with Redo/Undo logs and 2-Phase Commit)
P99 Latency Profile:1-3ms OLTP point read/write using clustered InnoDB primary keys
Architectural Highlights & Internals:
  • InnoDB Clustered Index: Table rows are physically organized according to the primary key, providing ultra-fast primary key index lookups.
  • Pluggable Storage Engine Architecture: Swap storage engines (InnoDB for transactions, Memory for caches, MyRocks for compression) per table.
  • Binary Log (Binlog) Replication: High-throughput asynchronous and semi-synchronous replication powering read-replica farms worldwide.
  • Ubiquitous Web Ecosystem: Supported by every web framework, ORM, cloud provider, and hosting infrastructure in existence.
InnoDB Clustered Index & CTE Query
-- Clustered index table layout for ultra-fast point queries
CREATE TABLE customer_orders (
    order_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    customer_id INT UNSIGNED NOT NULL,
    status ENUM('pending', 'paid', 'shipped') NOT NULL DEFAULT 'pending',
    order_total DECIMAL(10, 2) NOT NULL,
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (order_id),
    KEY idx_customer_created (customer_id, created_at)
) ENGINE=InnoDB ROW_FORMAT=DYNAMIC;

-- Recursive CTE for hierarchical catalog browsing
WITH RECURSIVE CategoryTree AS (
    SELECT id, name, parent_id, 0 AS depth
    FROM categories WHERE parent_id IS NULL
    UNION ALL
    SELECT c.id, c.name, c.parent_id, ct.depth + 1
    FROM categories c JOIN CategoryTree ct ON c.parent_id = ct.id
)
SELECT * FROM CategoryTree ORDER BY depth, name;
Sweet Spot: Web application backends, e-commerce platforms (WordPress, Shopify, Meta, Booking.com)
Superpowers:
  • + Ubiquitous ecosystem compatibility with virtually every programming language and ORM
  • + Clustered primary key indexing in InnoDB minimizes secondary lookups for primary key fetches
  • + Active enterprise-grade replication options including MySQL InnoDB Cluster and Vitess
Architectural Constraints:
  • - Less extensible than PostgreSQL (cannot easily define custom types, indexing operators)
  • - Historical quirks with SQL mode strictness and complex analytical query optimization
Official Docs & Spec
CockroachDB architecture blueprint
Distributed SQL (NewSQL)

CockroachDB

2015
Pioneered by: Spencer Kimball, Peter Mattis, Ben Darnell

CockroachDB is a cloud-native, distributed SQL database engineered to withstand hardware failures without human intervention—just like its namesake insect. Inspired by Google Spanner, CockroachDB offers standard PostgreSQL wire compatibility, horizontal auto-scaling, and strictly serializable ACID transactions across multi-region clusters by coordinating transactional ranges via the Raft consensus algorithm.

Storage Engine:Pebble (LSM-Tree Key-Value Engine in Go)
Storage Model:Ordered Key-Value to Relational Tables
Query Interface:PostgreSQL-Compatible SQL
Concurrency:Serializable Multi-Version Concurrency Control (MVCC) via Raft
ACID & Consistency:Strict Serializable ACID across multi-region distributed nodes
P99 Latency Profile:5-15ms globally distributed consensus transactions
Architectural Highlights & Internals:
  • Survives Node & Datacenter Outages: If a node dies, the cluster automatically rebalances and repairs data ranges without losing transactions.
  • Multi-Region Data Locality: Pin user data to specific continents/regions to comply with GDPR data sovereignty and ensure low-latency reads.
  • Raft Consensus Grouping: Data is divided into 64MB contiguous ranges, each replicated across nodes via independent Raft groups.
  • Standard PostgreSQL Wire Protocol: Works seamlessly with existing Postgres drivers, ORMs, and administrative tooling.
Multi-Region Distributed Table Locality
-- Define global survival goal and regional data residency
ALTER DATABASE banking_app SET PRIMARY REGION "us-east1";
ALTER DATABASE banking_app ADD REGION "us-west1";
ALTER DATABASE banking_app ADD REGION "europe-west1";

-- Row-level data locality keeps EU accounts in Europe for GDPR compliance
CREATE TABLE user_accounts (
    account_id UUID NOT NULL DEFAULT gen_random_uuid(),
    region crdb_internal_region NOT NULL,
    balance DECIMAL(15, 2) NOT NULL,
    currency VARCHAR(3) NOT NULL,
    PRIMARY KEY (region, account_id)
) LOCALITY REGIONAL BY ROW;
Sweet Spot: Mission-critical financial ledgers, multi-region cloud-native architectures, global resilient OLTP
Superpowers:
  • + True horizontal scaling with automated range rebalancing and split triggers
  • + Survives availability zone and regional data center failures with zero human intervention
  • + PostgreSQL wire-protocol compatible (compatible with PG drivers and ORMs)
Architectural Constraints:
  • - Higher write latency than single-node Postgres due to Raft quorum network round-trips
  • - Requires substantial CPU/RAM resources to run multi-node Raft coordination smoothly
Official Docs & Spec
Neo4j architecture blueprint
Graph Database (LPG)

Neo4j

2007
Pioneered by: Emil Eifrem, Johan Svensson, Peter Neubauer

Neo4j is the world's leading native graph database, designed from the storage layer up to leverage data relationships. While relational databases suffer exponential performance degradation when traversing recursive many-to-many joins, Neo4j uses 'index-free adjacency'—where each node holds direct physical memory pointers to its neighbors—allowing complex network paths and friend-of-friend lookups to execute in constant time.

Storage Engine:Native Graph Storage & Index-Free Adjacency
Storage Model:Labeled Property Graph (Nodes, Relationships, Properties)
Query Interface:Cypher Query Language (declarative graph SQL)
Concurrency:ACID Compliant (Native Graph Transaction Manager)
ACID & Consistency:Full ACID transactions
P99 Latency Profile:1-10ms index-free adjacency graph traversal regardless of total graph size
Architectural Highlights & Internals:
  • Index-Free Adjacency: Traversing relationships avoids expensive index lookups; navigating graphs requires only following direct memory pointers.
  • Cypher Graph Query Language: Visual, ASCII-art-inspired query syntax that represents relationships as (a)-[:KNOWS]->(b).
  • Native Graph Processing: Eliminates JOIN overhead for fraud detection, identity access management, recommendation engines, and knowledge graphs.
  • Graph Data Science (GDS): Built-in library of graph algorithms (PageRank, Louvain community detection, Dijkstra shortest path).
Cypher Pattern Match for Fraud Detection
// Detect circular money laundering cycles between bank accounts
MATCH path = (origin:Account)-[:TRANSFERRED_FUNDS*3..6]->(origin)
WHERE ALL(r IN relationships(path) WHERE r.amount > 10000)
RETURN [n IN nodes(path) | n.accountNumber] AS suspiciousCycle,
       length(path) AS cycleLength,
       reduce(total = 0, r IN relationships(path) | total + r.amount) AS totalAmountMoved
ORDER BY totalAmountMoved DESC
LIMIT 10;
Sweet Spot: Fraud rings detection, identity resolution, knowledge graphs, social networks, recommendation engines
Superpowers:
  • + Index-free adjacency: nodes point directly to memory pointers of adjacent edges
  • + Intuitive Cypher query language with declarative ASCII-art pattern matching
  • + Extensive Graph Data Science (GDS) library with PageRank, Louvain, and similarity algorithms
Architectural Constraints:
  • - Poor choice for simple tabular aggregate reports and bulk columnar analytics
  • - Large-scale horizontal sharding of deeply interconnected graphs is inherently complex
Official Docs & Spec
Qdrant architecture blueprint
Vector Database (AI / Similarity Search)

Qdrant

2021
Pioneered by: Andre Zayarni & Andrey Vasnetsov

Qdrant is an open-source vector database and vector search engine written in Rust. Tailored for production machine learning and generative AI applications, Qdrant stores high-dimensional dense embeddings produced by transformers and neural networks, allowing semantic similarity searches (k-NN) with combined scalar payload filtering at millisecond latencies.

Storage Engine:HNSW (Hierarchical Navigable Small World) + Payload Index
Storage Model:High-Dimensional Vector Embeddings + Metadata
Query Interface:gRPC & REST Vector Search API
Concurrency:Rust-Engineered Lock-Free Concurrency
ACID & Consistency:ACID write-ahead log on local segments; eventual consistency across cluster nodes
P99 Latency Profile:1-5ms sub-millisecond Approximate Nearest Neighbor (ANN) vector search
Architectural Highlights & Internals:
  • Written in Rust for Reliability: Zero-cost abstractions, predictable memory footprint, and rock-solid memory safety under heavy load.
  • Integrated Payload Filtering: Filter search results simultaneously by business metadata (tags, user IDs, price ranges) during vector graph traversal.
  • Optimized Quantization: Supports scalar and product quantization to compress vector sizes by up to 4x while maintaining high recall accuracy.
  • RAG & Semantic Retrieval Ready: Built directly for Retrieval-Augmented Generation (RAG) with OpenAI, Cohere, LangChain, and LlamaIndex.
Filtered Vector Similarity Search API
// POST /collections/documents/points/search
{
  "vector": [0.034, -0.012, 0.981, 0.442, -0.115],
  "limit": 5,
  "with_payload": true,
  "filter": {
    "must": [
      { "key": "category", "match": { "value": "database_internals" } },
      { "key": "published_year", "range": { "gte": 2024 } }
    ]
  },
  "params": {
    "hnsw_ef": 128,
    "exact": false
  }
}
Sweet Spot: Semantic AI search, Retrieval-Augmented Generation (RAG), multimodal image/audio similarity
Superpowers:
  • + High-performance memory-safe Rust core with SIMD-accelerated distance metrics (Cosine, Dot, Euclid)
  • + Payload-based filter-aware HNSW: filters metadata during graph traversal, preventing recall degradation
  • + Quantization support (Scalar, Product, Binary) reducing RAM footprint by up to 95%
Architectural Constraints:
  • - Specialized for vector embeddings and metadata filtering; not a general-purpose transactional database
  • - Large vector dimensions (e.g., 3072 dims) require substantial RAM without aggressive quantization
Official Docs & Spec
Meilisearch architecture blueprint
Search Engine / Full-Text Database

Meilisearch

2018
Pioneered by: Quentin de Quelen, Clément Renault, Thomas Payet

Meilisearch is a lightning-fast, open-source search engine written in Rust that delivers an instant search-as-you-type experience out of the box. Engineered as a nimble, developer-friendly alternative to heavy Elasticsearch clusters, Meilisearch provides typo tolerance, smart relevancy ranking, faceted filtering, and sub-50ms query responses without complex tuning.

Storage Engine:LMDB (Lightning Memory-Mapped Database)
Storage Model:Inverted Index + Prefix Tree
Query Interface:RESTful HTTP Search API
Concurrency:Multi-Threaded Read-Optimized Engine
ACID & Consistency:Transactional writes via LMDB key-value store
P99 Latency Profile:< 10ms typo-tolerant full-text search with instant search-as-you-type
Architectural Highlights & Internals:
  • Sub-50ms Search-As-You-Type: Instant responses on every keystroke create effortless search interfaces for e-commerce and documentation.
  • Typo Tolerance by Default: Intelligently understands spelling mistakes, phonetic slips, and partial words out of the box.
  • Built on Rust & LMDB: Zero garbage collection pauses, minimal RAM requirements, and rock-solid memory stability.
  • Configurable Ranking Rules: Tune relevancy deterministically using intuitive ranking rules (typo, words, proximity, attribute, exactness).
Instant Typo-Tolerant Search Query
import { MeiliSearch } from 'meilisearch';

const client = new MeiliSearch({ host: 'http://localhost:7700', apiKey: 'masterKey' });
const index = client.index('products');

// Fast search-as-you-type query with typo-tolerance & facet filtering
const searchResults = await index.search('postgre sql', {
  limit: 10,
  attributesToHighlight: ['title', 'description'],
  filter: 'category = "databases" AND in_stock = true',
  sort: ['rating:desc', 'price:asc'],
  facets: ['brand', 'category']
});

console.log('Search latency:', searchResults.processingTimeMs, 'ms');
Sweet Spot: Search-as-you-type search bars, e-commerce storefront search, documentation site search
Superpowers:
  • + Ultra-fast instant search designed specifically for frontend input search boxes
  • + Built-in advanced typo tolerance, synonym expansion, and prefix matching out of the box
  • + Zero-configuration ranking rules (Words, Typo, Proximity, Attribute, Sort, Exactness)
Architectural Constraints:
  • - Not designed for massive distributed petabyte log analytics (unlike Elasticsearch)
  • - Dataset must comfortably fit into disk memory-map (RAM/swap) for peak performance
Official Docs & Spec
RocksDB architecture blueprint
Embedded Key-Value Storage Engine

RocksDB

2012
Pioneered by: Facebook Database Engineering (Forked from Google LevelDB)

RocksDB is a high-performance, embedded database for key-value data developed by Meta. Forked from Google's LevelDB, RocksDB is heavily optimized for fast flash storage, NVMe SSDs, and multicore processors. Rather than serving end users directly, RocksDB acts as the foundational internal storage engine powering databases like CockroachDB, TiDB, Kafka Streams, and Apache Flink.

Storage Engine:Log-Structured Merge-Tree (LSM-Tree)
Storage Model:Byte-Array Key-Value Store
Query Interface:C++ Programmatic API (Get / Put / Delete / Iterator)
Concurrency:Multi-Threaded Compaction & Lock-Free Reads
ACID & Consistency:Atomic writes via Write-Ahead Log (WAL) and WriteBatch; point-in-time snapshots
P99 Latency Profile:< 100 microseconds fast key lookup | tens of thousands of writes/sec
Architectural Highlights & Internals:
  • Optimized for High-Throughput SSDs: Transforms random write workloads into sequential disk operations via Log-Structured Merge-Trees.
  • Universal Database Engine: Serves as the bedrock storage engine for distributed databases, streaming pipelines, and state stores.
  • Tunable LSM Compaction: Offers Leveled, Universal, and FIFO compaction strategies to balance write amplification, space, and read latency.
  • Column Families & Bloom Filters: Organizes data into isolated key spaces and leverages Bloom filters to avoid unnecessary disk probes.
C++ High-Performance WriteBatch
#include <rocksdb/db.h>
#include <rocksdb/options.h>

rocksdb::DB* db;
rocksdb::Options options;
options.create_if_missing = true;
options.compression = rocksdb::kLZ4Compression;

rocksdb::Status status = rocksdb::DB::Open(options, "/data/rocks_store", &db);

// Atomic multi-operation WriteBatch
rocksdb::WriteBatch batch;
batch.Put("user:1001:profile", "{'name':'Guigo'}");
batch.Delete("user:1001:temp_token");
rocksdb::WriteOptions write_options;
write_options.sync = true; // Guarantees durable disk fsync

db->Write(write_options, &batch);
Sweet Spot: Underlying storage engine for CockroachDB, TiKV, Kafka Streams, Ceph, RocksJava
Superpowers:
  • + Log-Structured Merge-tree (LSM-tree) delivers unmatched write performance on modern SSDs
  • + Highly customizable compaction algorithms (Leveled, Universal, FIFO) and memory tuning
  • + Zero network hops: compiles directly into C++, Rust, Go, and Java host binaries
Architectural Constraints:
  • - Raw C++ key-value engine with no SQL parser, query planner, or network layer
  • - Space and read amplification can degrade performance without proper compaction tuning
Official Docs & Spec
TimescaleDB architecture blueprint
Time-Series Relational DBMS

TimescaleDB

2017
Pioneered by: Ajay Kulkarni & Michael Freedman

TimescaleDB is an open-source time-series database engineered as an extension to PostgreSQL. It provides the reliability, full SQL power, and extensive tooling of Postgres, while delivering the massive write throughput, compression (up to 95%), and automated chunking required to manage millions of metrics, IoT sensor readings, and financial market ticks per second.

Storage Engine:PostgreSQL Engine + Partitioned Hypertables
Storage Model:Chunk-Partitioned Hybrid Row/Columnar
Query Interface:SQL (Native PostgreSQL + Time-Series Functions)
Concurrency:PostgreSQL ACID Concurrency
ACID & Consistency:Full ACID (Inherits all PostgreSQL transactional guarantees)
P99 Latency Profile:1-5ms point time-series queries; 10x-100x analytical aggregation speedups
Architectural Highlights & Internals:
  • Hypertables Abstraction: Appears to users as a standard SQL table but partitions transparently into smaller time/space chunks behind the scenes.
  • Hybrid Compression: Automatically converts older historical row chunks into columnar storage formats, cutting disk footprints by 90-95%.
  • Native Time-Series SQL Functions: Built-in time_bucket(), locf(), gap-filling, and rolling window analytical functions.
  • Full PostgreSQL Compatibility: Join time-series telemetry directly with business relational metadata, user profiles, and spatial GIS tables.
Hypertables & Automated Continuous Aggregates
-- Convert standard table into an automated hypertable
SELECT create_hypertable('server_metrics', 'timestamp', chunk_time_interval => INTERVAL '1 day');

-- Create real-time continuous aggregate materialized view
CREATE MATERIALIZED VIEW hourly_cpu_summary
WITH (timescaledb.continuous) AS
SELECT 
    time_bucket('1 hour', timestamp) AS bucket,
    server_id,
    avg(cpu_percent) AS avg_cpu,
    max(cpu_percent) AS max_cpu
FROM server_metrics
GROUP BY bucket, server_id;

-- Enable automated 90% columnar compression on data older than 7 days
ALTER TABLE server_metrics SET (timescaledb.compress, timescaledb.compress_segmentby = 'server_id');
SELECT add_compression_policy('server_metrics', INTERVAL '7 days');
Sweet Spot: DevOps monitoring, financial tick data, smart grid sensor metrics, industrial IoT telemetry
Superpowers:
  • + Automatic partitioning via Hypertables across both time intervals and space keys
  • + Columnar compression algorithms achieve 90%+ disk space reduction on historical data
  • + Full SQL compatibility: join real-time sensor metrics directly with business customer tables
Architectural Constraints:
  • - Inherits PostgreSQL process-model scaling constraints under massive concurrency
  • - Hypertable chunk creation must be tuned carefully to prevent too many small chunks in RAM
Official Docs & Spec
TiDB architecture blueprint
Distributed HTAP (Hybrid Transactional & Analytical)

TiDB

2015
Pioneered by: PingCAP (Max Liu, Ed Huang, Dongxu Huang)

TiDB (Titanium DB) is an open-source distributed NewSQL database that supports Hybrid Transactional and Analytical Processing (HTAP). Designed with a decoupled architecture separating stateless SQL compute from stateful storage, TiDB provides MySQL syntax compatibility, horizontal scalability, and real-time business intelligence without separate ETL pipelines.

Storage Engine:TiKV (Row/Raft) + TiFlash (Columnar/Raft)
Storage Model:Dual Row & Columnar Storage
Query Interface:MySQL-Compatible SQL
Concurrency:Multi-Raft Distributed Percolator Transactions
ACID & Consistency:Strict Serializable ACID (Percolator distributed transaction model)
P99 Latency Profile:2-10ms distributed OLTP; sub-second HTAP real-time analytics
Architectural Highlights & Internals:
  • True HTAP Architecture: Replicates transactional row data in TiKV into columnar TiFlash storage asynchronously via Raft learner nodes.
  • Decoupled Compute & Storage: Stateless TiDB compute nodes scale independently from TiKV storage layers to handle fluctuating traffic spikes.
  • MySQL Protocol Compatibility: Drop-in replacement for MySQL clusters, eliminating manual sharding with Vitess or ProxySQL.
  • Global ACID Transactions: Distributed transactions implemented via an enhanced Google Percolator model with snapshot isolation.
Dual-Engine HTAP Cost-Based Routing
-- Enable real-time columnar replica for an existing transactional table
ALTER TABLE ecommerce_orders SET TIFLASH REPLICA 1;

-- TiDB cost-based optimizer automatically routes transactional writes to TiKV 
-- and massive analytical aggregations to vectorized TiFlash columnar engine
SELECT 
    /*+ READ_FROM_STORAGE(TIFLASH[ecommerce_orders]) */
    category,
    sum(amount) AS total_sales,
    count(DISTINCT customer_id) AS active_buyers
FROM ecommerce_orders
WHERE order_date >= '2026-01-01'
GROUP BY category;
Sweet Spot: Large-scale e-commerce, banking, real-time hybrid transactional/analytical processing (HTAP)
Superpowers:
  • + True HTAP: combines row-based storage (TiKV) for OLTP with columnar storage (TiFlash) for OLAP
  • + Drop-in MySQL 5.7/8.0 wire protocol compatibility without changing application SQL
  • + Seamless online horizontal scaling: add nodes to expand storage and compute independently
Architectural Constraints:
  • - Complex multi-component operational topology (TiDB stateless servers, PD coordinators, TiKV, TiFlash)
  • - Noticeable baseline latency for trivial single-row queries compared to a local MySQL instance
Official Docs & Spec
ScyllaDB architecture blueprint
High-Throughput Wide-Column NoSQL

ScyllaDB

2015
Pioneered by: Avi Kivity & Dor Laor

ScyllaDB is a distributed, high-performance NoSQL database designed as a drop-in C++ replacement for Apache Cassandra and Amazon DynamoDB. By utilizing the Seastar asynchronous C++ framework and a thread-per-core shared-nothing architecture, ScyllaDB eliminates JVM garbage collection pauses, delivering 10x higher throughput and consistent sub-millisecond P99 latencies.

Storage Engine:Seastar Shared-Nothing Asynchronous C++ Engine
Storage Model:Wide-Column Family / SSTables
Query Interface:CQL (Cassandra) & Amazon DynamoDB API
Concurrency:Thread-per-Core Shared-Nothing Asynchronous Architecture
ACID & Consistency:BASE / Tunable Consistency (AP system, compatible with Cassandra/DynamoDB)
P99 Latency Profile:< 1ms ultra-low P99 latency at millions of operations/sec
Architectural Highlights & Internals:
  • Shared-Nothing Thread-Per-Core: Pinning threads to CPU cores eliminates lock contention, inter-thread context switching, and memory barriers.
  • No JVM Garbage Collection: Rewritten entirely in modern C++ to eliminate unpredictable stop-the-world Java GC latency spikes.
  • Dual Protocol Support: Native support for both Cassandra Query Language (CQL) and Amazon DynamoDB REST endpoints (Alternator).
  • Autonomous Resource Balancing: Dynamically balances CPU, RAM, and disk I/O between background compactions and foreground queries.
High-Volume Telemetry Schema in CQL
-- ScyllaDB table pinning partition key to CPU-core shards
CREATE KEYSPACE telemetry_feed WITH replication = {
    'class': 'NetworkTopologyStrategy', 
    'us-east': 3
};

CREATE TABLE telemetry_feed.ad_impressions (
    campaign_id uuid,
    ad_unit_id text,
    event_timestamp timestamp,
    user_fingerprint text,
    bid_price_micros bigint,
    PRIMARY KEY ((campaign_id, ad_unit_id), event_timestamp)
) WITH CLUSTERING ORDER BY (event_timestamp DESC);
Sweet Spot: Extreme-throughput real-time ad serving, cybersecurity threat intelligence, game states
Superpowers:
  • + Share-nothing asynchronous C++ Seastar engine delivers 10x throughput of Java Cassandra
  • + Eliminates JVM garbage collection pauses, delivering predictable sub-millisecond P99 latency
  • + 100% protocol and driver compatible with Apache Cassandra and Amazon DynamoDB (Alternator)
Architectural Constraints:
  • - Rigid query patterns dictated by primary partition keys (no dynamic arbitrary JOINs)
  • - Requires dedicated hardware or high-performance NVMe cloud instances for maximum efficiency
Official Docs & Spec
Milvus architecture blueprint
Distributed Vector Database

Milvus

2019
Pioneered by: Zilliz

Milvus is an open-source, distributed vector database engineered to store, index, and query billions of high-dimensional vector embeddings. Designed from inception as a cloud-native disaggregated system, Milvus separates storage from computing and supports GPU acceleration, DiskANN SSD indexes, and hybrid similarity search for massive AI workloads.

Storage Engine:Knowhere Vector Core (HNSW, IVF-PQ, DiskANN, GPU)
Storage Model:Vector Embeddings + Scalar Fields
Query Interface:Milvus SDKs / REST / gRPC
Concurrency:Cloud-Native Microservices Disaggregated Architecture
ACID & Consistency:Eventual consistency with tunable bounded-staleness consistency levels
P99 Latency Profile:1-10ms billion-scale Approximate Nearest Neighbor vector search
Architectural Highlights & Internals:
  • Billion-Scale Vector Capacity: Scales to tens of billions of vectors through cloud-native sharding and distributed query nodes.
  • Hardware Acceleration (GPU/SIMD): Harnesses NVIDIA GPUs and CPU SIMD (AVX-512) for ultra-fast vector index construction and search.
  • Pluggable Indexing Algorithms: Supports comprehensive vector indexing strategies including HNSW, IVF_FLAT, IVF_SQ8, IVF_PQ, and DiskANN.
  • Storage & Compute Disaggregation: Built on top of cloud object storage (S3/MinIO) and message logs (Kafka/Pulsar) for elasticity.
Billion-Scale Milvus Vector Search
from pymilvus import Collection

collection = Collection("knowledge_embeddings")

# Build HNSW index with M=16, efConstruction=200
index_params = {
    "metric_type": "COSINE",
    "index_type": "HNSW",
    "params": {"M": 16, "efConstruction": 200}
}
collection.create_index(field_name="vector", index_params=index_params)
collection.load()

# Execute fast k-NN vector search with scalar expression filter
results = collection.search(
    data=[[0.015, -0.045, 0.821, ...]], # query embedding
    anns_field="vector",
    param={"metric_type": "COSINE", "params": {"ef": 64}},
    limit=5,
    expr="year >= 2024 and category == 'ai_research'",
    output_fields=["title", "url"]
)
Sweet Spot: Massive billion-scale enterprise vector search, multimodal image retrieval, LLM agents
Superpowers:
  • + Disaggregated cloud-native architecture separates query nodes, data nodes, and index builders
  • + Supports extensive indexing algorithms (HNSW, IVF-FLAT, IVF-PQ, SCaNN, DiskANN)
  • + DiskANN allows searching billions of vector embeddings directly on SSDs with minimal RAM
Architectural Constraints:
  • - High operational complexity with dependencies on object storage, Kafka/Pulsar, and etcd
  • - Excessive overhead for small vector collections (< 100,000 vectors)
Official Docs & Spec
ChromaDB architecture blueprint
AI-Native Embedding Database

ChromaDB

2022
Pioneered by: Jeff Huber & Anton Troynikov

Chroma is an open-source, AI-native embedding database designed to simplify the development of LLM applications. Focused on ergonomics and simplicity, Chroma allows developers to plug embeddings, document text, and metadata directly into memory or local storage, forming the default knowledge layer for conversational agents, LangChain apps, and personal AI tools.

Storage Engine:HNSWlib + ClickHouse/SQLite Backend
Storage Model:Embedding Vector + Document Text + Metadata
Query Interface:Python & TypeScript Native APIs
Concurrency:Single-Process / Client-Server Async
ACID & Consistency:Eventual consistency on embedded SQLite/ClickHouse + HNSW segments
P99 Latency Profile:2-10ms embedded vector retrieval
Architectural Highlights & Internals:
  • Developer-First Ergonomics: Get started in 4 lines of Python or TypeScript code without running complex cluster infrastructure.
  • Integrated Embedding Functions: Automatically converts input raw text strings into vector embeddings using Hugging Face or OpenAI models.
  • Document & Metadata Bundling: Stores the source text document, metadata dictionary, and vector coordinate together in a single queryable entity.
  • Rapid Prototyping to Production: Seamlessly transition from an in-memory test database to a persistent client-server deployment.
Embedded ChromaDB RAG Pipeline
import chromadb
from chromadb.utils import embedding_functions

# Initialize persistent local embedded vector database
client = chromadb.PersistentClient(path="./chroma_data")
collection = client.get_or_create_collection(
    name="technical_docs",
    metadata={"hnsw:space": "cosine"}
)

# Insert documents with metadata
collection.add(
    documents=["DuckDB uses vectorized SIMD execution.", "PostgreSQL handles MVCC via heap files."],
    metadatas=[{"source": "duckdb_guide"}, {"source": "postgres_internals"}],
    ids=["doc1", "doc2"]
)

# Semantic retrieval for AI query
results = collection.query(
    query_texts=["How does vectorized column processing work?"],
    n_results=1,
    where={"source": "duckdb_guide"}
)
Sweet Spot: Local LLM development, LangChain/LlamaIndex RAG pipelines, AI agent memory
Superpowers:
  • + Easiest setup in the AI ecosystem: zero Docker requirement, runs directly in Python/JS memory
  • + Built-in automatic text embedding functions (OpenAI, HuggingFace, sentence-transformers)
  • + Integrated metadata filtering combined with vector cosine/L2 distance search
Architectural Constraints:
  • - Not suited for large-scale distributed enterprise deployments exceeding tens of millions of vectors
  • - Single-writer concurrency limitations when using embedded SQLite persistence
Official Docs & Spec
LMDB architecture blueprint
Micro Embedded Key-Value Store

LMDB

2011
Pioneered by: Howard Chu (Symas / OpenLDAP)

Lightning Memory-Mapped Database (LMDB) is an ultra-fast, compact embedded key-value data store developed for the OpenLDAP project. By mapping the database file directly into the application's virtual memory space via mmap, LMDB eliminates internal caches, buffer copying, and thread locking for readers, delivering millions of read operations per second per CPU core.

Storage Engine:Memory-Mapped B+Tree (mmap)
Storage Model:Ordered Byte-Array Keys and Values
Query Interface:C Native Library API
Concurrency:Lock-Free Single-Writer / Infinite Concurrent Readers
ACID & Consistency:Full ACID (Copy-On-Write B+ Tree; single-writer with wait-free concurrent readers)
P99 Latency Profile:< 5 microseconds microsecond read latencies via direct mmap()
Architectural Highlights & Internals:
  • Zero-Copy Memory Mapping: Reads return direct pointers into the operating system's page cache, achieving near-hardware speed.
  • Crash-Proof Copy-On-Write B+Tree: Never overwrites live pages; atomic root pointer swaps guarantee integrity without recovery logs.
  • Tiny Code Footprint: The entire engine consists of under 10,000 lines of pristine, dependency-free C code in a single header and C file.
  • Lock-Free Concurrent Readers: Readers never block writers and writers never block readers, scaling linearly with available CPU cores.
C LMDB Zero-Copy mmap() Transaction
#include <lmdb.h>

MDB_env *env;
MDB_dbi dbi;
MDB_txn *txn;
MDB_val key, data;

mdb_env_create(&env);
mdb_env_set_mapsize(env, 10485760); // 10MB virtual address map
mdb_env_open(env, "./lmdb_store", 0, 0664);

// Zero-copy read transaction (runs concurrently with zero lock contention)
mdb_txn_begin(env, NULL, MDB_RDONLY, &txn);
mdb_dbi_open(txn, NULL, 0, &dbi);

key.mv_size = 4;
key.mv_data = "1001";
mdb_get(txn, dbi, &key, &data);

// data.mv_data points DIRECTLY into kernel page cache (zero copy)
printf("Record size: %zu bytes\n", data.mv_size);
mdb_txn_abort(txn);
Sweet Spot: OpenLDAP directory service, machine learning training datasets (Caffe/PyTorch), high-speed key-value caches
Superpowers:
  • + Zero-copy read performance: applications read directly from OS virtual memory page cache via mmap()
  • + Immune to database corruption: Copy-on-Write B+ tree ensures safe crash recovery without a WAL
  • + Ridiculously small footprint: ~32KB compiled C code with zero external library dependencies
Architectural Constraints:
  • - Single writer lock: only one write transaction can execute at a given moment
  • - Database file pre-allocates contiguous virtual address space, requiring a large mapsize upfront
Official Docs & Spec
PGlite architecture blueprint
WASM In-Process PostgreSQL

PGlite

2024
Pioneered by: ElectricSQL Team

PGlite is a lightweight WebAssembly build of full PostgreSQL packaged into a tiny JavaScript/TypeScript client library (~3MB gzipped). It allows running a real, compliant Postgres database inside web browsers, Node.js, Bun, and Deno runtimes, persisting data directly to browser IndexedDB or running ephemerally in RAM.

Storage Engine:Compiled PostgreSQL Engine (Emscripten WebAssembly)
Storage Model:PostgreSQL Heap & Indexes in Memory / IndexedDB
Query Interface:Full PostgreSQL SQL
Concurrency:Single-Threaded WASM Sandbox
ACID & Consistency:Full ACID (Complete PostgreSQL transactional semantics in WASM)
P99 Latency Profile:< 5ms in-memory WebAssembly SQL execution in browser tab or Node.js
Architectural Highlights & Internals:
  • Real Postgres in WebAssembly: Not an emulator or dialect; runs official PostgreSQL source code compiled to WASM.
  • Browser & Edge Persistence: Persist data seamlessly to browser IndexedDB or the local filesystem with zero external server dependencies.
  • Extension Support: Includes support for essential extensions like pgvector for client-side semantic AI search right inside the user's browser.
  • Ultra-Fast Test Execution: Spawns ephemeral PostgreSQL instances for unit tests in tens of milliseconds without Docker containers.
PGlite In-Browser WebAssembly Query
import { PGlite } from '@electric-sql/pglite';
import { vector } from '@electric-sql/pglite/vector';

// Initialize PGlite with persistent IndexedDB backing & pgvector
const db = new PGlite('idb://my-local-postgres', {
  extensions: { vector }
});

await db.exec('CREATE EXTENSION IF NOT EXISTS vector;');
await db.exec(`
  CREATE TABLE IF NOT EXISTS notes (
    id SERIAL PRIMARY KEY,
    content TEXT,
    embedding vector(3)
  );
`);

// Execute transactional query in browser tab
await db.query(
  'INSERT INTO notes (content, embedding) VALUES ($1, $2)',
  ['Offline-first AI memory', '[0.1, 0.2, 0.3]']
);

const res = await db.query('SELECT * FROM notes;');
console.log('PGlite rows in browser:', res.rows);
Sweet Spot: Local-first web apps, edge computing (Cloudflare Workers), offline-capable PWAs, browser tests
Superpowers:
  • + Runs genuine PostgreSQL in WebAssembly with zero external dependencies and ~3MB gzip size
  • + Persists state directly into browser IndexedDB or runs completely in RAM
  • + Supports PostgreSQL extensions including pgvector right inside client-side JavaScript
Architectural Constraints:
  • - Subject to browser WebAssembly memory limits (typically 2GB-4GB address space)
  • - Single-user in-process model; not intended to replace multi-tenant server PostgreSQL
Official Docs & Spec
Apache Druid architecture blueprint
Real-Time Distributed OLAP

Apache Druid

2011
Pioneered by: Fangjin Yang, Eric Tschetter, Gian Merlino (Metamarkets)

Apache Druid is a high-performance, real-time analytics database designed for sub-second queries on streaming and batch data. Designed to power interactive user-facing dashboards and operational event streams, Druid combines column-oriented storage, inverted bitmap indexes, and automatic data rollups to deliver sub-second queries on multi-billion-row datasets.

Storage Engine:Columnar Storage with Bitmap Inverted Indexes
Storage Model:Segment-Based Columnar / Time-Partitioned
Query Interface:Druid SQL & Native JSON Query Language
Concurrency:Disaggregated Multi-Node Distributed Cluster
ACID & Consistency:Atomic immutable segment publishing; eventual consistency across historical nodes
P99 Latency Profile:10-100ms sub-second slice-and-dice queries on streaming event streams
Architectural Highlights & Internals:
  • Sub-Second Response Times: Engineered specifically for interactive OLAP slice-and-dice exploratory user interfaces at scale.
  • Real-Time Stream Ingestion: Ingests directly from Apache Kafka and AWS Kinesis with immediate event queryability without batch delays.
  • Roaring Bitmap Inverted Indexes: Extremely fast multi-column filtering and boolean evaluations on high-cardinality event streams.
  • Automatic Ingestion Rollups: Summarizes and pre-aggregates raw telemetry during ingestion, drastically reducing required cluster storage.
Druid Sub-Second Streaming Timeseries
-- Real-time slice-and-dice query using exact bitmap indexing
SELECT 
    TIME_FLOOR(__time, 'PT5M') AS time_interval,
    datacenter,
    country_code,
    COUNT(*) AS total_requests,
    APPROX_COUNT_DISTINCT_BUILTIN(user_id) AS approx_unique_users,
    APPROX_QUANTILE_DS(response_time_ms, 0.99) AS p99_latency_ms
FROM "telemetry_traffic"
WHERE __time >= CURRENT_TIMESTAMP - INTERVAL '1' HOUR
  AND status_code >= 500
GROUP BY 1, 2, 3
ORDER BY total_requests DESC;
Sweet Spot: Interactive real-time user-facing analytics dashboards, ad-tech auction analysis, APM telemetry
Superpowers:
  • + Sub-second interactive query latencies on multi-petabyte datasets via Roaring bitmap indexing
  • + Native Kafka and Kinesis streaming ingestion with zero-delay indexing into queryable segments
  • + Automatic data rollup during ingestion condenses raw streaming events by up to 90%
Architectural Constraints:
  • - Complex distributed topology (Brokers, Historicals, MiddleManagers, Overlords, ZooKeeper)
  • - Not designed for transactional single-record row mutations or frequent ad-hoc joins
Official Docs & Spec
Apache Pinot architecture blueprint
User-Facing Real-Time OLAP

Apache Pinot

2015
Pioneered by: LinkedIn Engineering (Kishore Gopalakrishna et al.)

Apache Pinot is a real-time distributed OLAP datastore designed to deliver low-latency analytics at extreme query throughput. Created at LinkedIn to power user-facing products like 'Who Viewed My Profile' and newsfeed analytics, Pinot can execute complex aggregation queries over billions of records with P99 latencies under 50 milliseconds while serving hundreds of thousands of concurrent users.

Storage Engine:Star-Tree & Columnar Segment Engine
Storage Model:Distributed Segment Columnar
Query Interface:PQL / Standard SQL
Concurrency:High Concurrency (Thousands of Queries Per Second)
ACID & Consistency:Immutable columnar segments; atomic segment swaps and eventual consistency
P99 Latency Profile:< 50ms distributed real-time OLAP on streaming Kafka events
Architectural Highlights & Internals:
  • High QPS for User-Facing Analytics: Unlike internal data warehouses, Pinot is built to serve thousands of concurrent external end users.
  • Star-Tree Indexing: Pre-aggregates multidimensional data across key dimensions, bypassing costly table scans at query time.
  • Pluggable Index Architecture: Leverages Forward, Inverted, Range, Text, JSON, Timestamp, and Bloom indexes per column.
  • Real-Time Kafka/Pulsar Ingestion: Guarantees immediate consistency between streaming event brokers and queryable segments.
Pinot Ultra-Low Latency Star-Tree Query
-- User-facing high-QPS query accelerated by Star-Tree index
SELECT 
    member_country,
    company_industry,
    COUNT(*) AS profile_views,
    DISTINCTCOUNT(viewer_member_id) AS unique_viewers
FROM profile_impressions
WHERE viewed_timestamp >= now() - 86400000
  AND target_member_id = 948291
GROUP BY member_country, company_industry
ORDER BY profile_views DESC
LIMIT 10;
Sweet Spot: User-facing real-time analytics (LinkedIn 'Who Viewed My Profile', Uber Eats restaurant metrics)
Superpowers:
  • + Engineered specifically for high-QPS user-facing analytics under thousands of concurrent queries
  • + Specialized indexing: Star-Tree, Inverted, Range, Bloom filter, Text, and Geospatial indexes
  • + Real-time streaming ingestion directly from Apache Kafka without intermediate micro-batching
Architectural Constraints:
  • - Requires Apache Helix, ZooKeeper, Controller, Broker, and Server cluster components
  • - Limited support for complex arbitrary multi-table JOIN operations
Official Docs & Spec
Elasticsearch architecture blueprint
Distributed Search & Analytics

Elasticsearch

2010
Pioneered by: Shay Banon

Elasticsearch is a distributed, RESTful search and analytics engine built on Apache Lucene. Renowned as the core of the Elastic Stack (ELK), it powers enterprise search engines, security operations centers (SIEM), and observability pipelines by indexing semi-structured JSON documents across distributed shards.

Storage Engine:Apache Lucene (Inverted Index, BKD Trees, DocValues)
Storage Model:JSON Document Store
Query Interface:Query DSL (JSON-based) & ES|QL
Concurrency:Cluster Sharding & Optimistic Concurrency Control
ACID & Consistency:Near Real-Time (NRT) eventual consistency (translog write buffer + Lucene segment flushes)
P99 Latency Profile:5-25ms distributed full-text search and analytical aggregations
Architectural Highlights & Internals:
  • Apache Lucene Foundation: State-of-the-art inverted index algorithms deliver linguistic stemming, tokenization, and fuzzy term matching.
  • Distributed Sharded Architecture: Automatically balances indices across cluster nodes for high availability and fault tolerance.
  • Doc Values for Aggregations: Columnar on-disk data structures allow real-time statistical aggregations and histogram analysis.
  • Enterprise Observability & SIEM: The global backbone for IT log management, threat hunting, application telemetry, and monitoring.
BM25 Search with Multi-Match & Highlighting
// POST /logs-application/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "multi_match": {
            "query": "database transaction deadlock",
            "fields": ["title^3", "message", "stack_trace"]
          }
        }
      ],
      "filter": [
        { "term": { "environment": "production" } },
        { "range": { "@timestamp": { "gte": "now-24h" } } }
      ]
    }
  },
  "highlight": {
    "fields": { "message": {} }
  },
  "aggs": {
    "errors_by_service": {
      "terms": { "field": "service.name.keyword", "size": 5 }
    }
  }
}
Sweet Spot: Enterprise full-text search, ELK stack log analysis, security SIEM intelligence, application monitoring
Superpowers:
  • + World-class Lucene inverted index foundation with linguistic tokenizers and stemmers
  • + Massive distributed scalability handling petabytes of log data across hundreds of shards
  • + Rich aggregation framework allowing nested, bucket, and pipeline metrics queries
Architectural Constraints:
  • - High RAM and heap consumption (heavy JVM garbage collection tuning required)
  • - High storage amplification due to maintaining both inverted index, doc_values, and _source
Official Docs & Spec
Apache CouchDB architecture blueprint
Document Store with Offline Sync

Apache CouchDB

2005
Pioneered by: Damien Katz

Apache CouchDB is an open-source document database built for distributed web architectures and unreliable networks. Implemented in Erlang for fault tolerance, CouchDB treats HTTP and REST as first-class citizens and is famous for its master-master replication protocol, allowing nodes and offline mobile clients (via PouchDB) to synchronize bidirectionally whenever a network connection is available.

Storage Engine:Append-Only B-Tree (CouchStore)
Storage Model:JSON Documents with Binary Attachments
Query Interface:Mango Query (JSON) & MapReduce Views
Concurrency:MVCC (Multi-Version Concurrency Control) with Revisions
ACID & Consistency:Eventual consistency across distributed nodes (MVCC with document revisions _rev)
P99 Latency Profile:2-10ms JSON document reads and atomic writes
Architectural Highlights & Internals:
  • CouchDB Replication Protocol: Industry standard for bidirectional multi-master synchronization, handling conflict resolution gracefully.
  • PouchDB Browser Sync: Pair with in-browser PouchDB for seamless offline-first web apps that sync when internet connectivity restores.
  • Pure HTTP/JSON REST Interface: Query, insert, update, and manage databases using standard HTTP methods (GET, PUT, POST, DELETE).
  • Crash-Resilient Append-Only Storage: File corruption is nearly impossible because writes are appended sequentially without in-place edits.
CouchDB HTTP REST API & MapReduce View
# Insert JSON document with revision control over standard HTTP
curl -X PUT http://admin:[email protected]:5984/inventory/item_884 \
  -H "Content-Type: application/json" \
  -d '{"name": "Database Internals Book", "stock": 42, "category": "engineering"}'

# JavaScript MapReduce View definition
function(doc) {
  if (doc.category && doc.stock) {
    emit(doc.category, doc.stock);
  }
}
// Reduce function
_sum
Sweet Spot: Offline-first sync architectures, mobile field deployments, CouchDB-to-PouchDB browser sync
Superpowers:
  • + Native HTTP RESTful JSON API requiring zero proprietary drivers or connection protocols
  • + Unmatched multi-master bidirectional sync: perfect for unreliable networks and edge nodes
  • + Seamless client pairing with PouchDB running inside browsers and mobile apps
Architectural Constraints:
  • - Append-only B-tree file requires periodic compaction to reclaim disk space from old revisions
  • - Conflict resolution requires application logic to handle diverging document revisions
Official Docs & Spec
SurrealDB architecture blueprint
Multi-Model (Document, Graph, Temporal, Vector)

SurrealDB

2021
Pioneered by: Toby Eyre & Jaime Eyre

SurrealDB is an end-to-end cloud-native multi-model database developed in Rust. Combining the capabilities of a relational database, document store, graph database, and vector index into a single unified engine, SurrealDB allows developers to query nested documents, traverse graph relationships with pointer syntax, and enforce row-level security directly from web clients without a traditional backend server.

Storage Engine:Pluggable (TiKV, RocksDB, Memory, IndexedDB)
Storage Model:Multi-Model Schemafull / Schemaless
Query Interface:SurrealQL (SQL-like language with graph relations)
Concurrency:ACID Transactional Engine (Rust-based)
ACID & Consistency:Full ACID (Multi-table transactions supported natively)
P99 Latency Profile:1-5ms multi-model document, graph, and vector queries
Architectural Highlights & Internals:
  • Unified Multi-Model Vision: Query tables as documents, link entities with directional graph edges, and perform vector similarity in one system.
  • SurrealQL Expressiveness: Intuitive syntax combining SQL declarative power with graph traversal: SELECT ->purchased->product.name FROM user.
  • Built-in Permissions & Auth: Fine-grained row-level access control (RBAC) allows frontend clients to query the database directly.
  • Runs Everywhere: Operates in-memory, embedded in WebAssembly, on local SSDs via RocksDB, or distributed at scale over TiKV.
SurrealQL Graph & Vector Hybrid Query
-- Create graph relation between users and products
RELATE user:guigo->purchased->product:db_course 
SET purchased_at = time::now(), discount = 15;

-- Traverse graph relationships with arrow syntax in SurrealQL
SELECT 
    name, 
    ->purchased->product.title AS courses_bought,
    ->purchased->product<-purchased<-user.name AS also_bought_by
FROM user:guigo;

-- Subscribe to real-time database mutations via WebSocket
LIVE SELECT * FROM order WHERE status = 'pending';
Sweet Spot: Modern full-stack web applications, real-time live queries, unified graph and document backends
Superpowers:
  • + Unified multi-model: use document, graph relations, time-series, and vector search in one engine
  • + SurrealQL syntax blends intuitive SQL with graph traversals and nested JSON pointers
  • + Real-time Live Queries stream database mutations directly to frontend WebSocket clients
Architectural Constraints:
  • - Younger ecosystem and toolchain compared to mature 20-year-old relational engines
  • - Rapid feature evolution may introduce breaking changes between major versions
Official Docs & Spec
Memcached architecture blueprint
Distributed In-Memory Key-Value Cache

Memcached

2003
Pioneered by: Brad Fitzpatrick (LiveJournal / Danga Interactive)

Memcached is an open-source, high-performance, distributed memory object caching system designed to speed up dynamic database-driven websites by alleviating database load. With a minimalist design focused strictly on key-value string/byte caching, Memcached utilizes a slab allocator to avoid RAM fragmentation and serves millions of cached pages per second.

Storage Engine:Slab Allocator in RAM (LRU Eviction)
Storage Model:Flat String/Byte-Array Key-Value
Query Interface:Text & Binary Protocol (get / set / delete)
Concurrency:Multi-Threaded Event-Driven (libevent)
ACID & Consistency:No ACID guarantees (Volatile distributed in-memory cache)
P99 Latency Profile:< 200 microseconds ultra-low sub-millisecond memory cache lookup
Architectural Highlights & Internals:
  • Minimalist High-Throughput Design: Doing one thing exceptionally well: volatile key-value caching with microsecond lookups.
  • Multi-Threaded Architecture: Scales efficiently across modern multi-core server processors with thread-safe locking.
  • Slab Allocation Memory Model: Pre-allocates fixed-size memory slabs to completely avoid OS memory fragmentation under high turnover.
  • LRU Cache Eviction: Automatically purges least-recently-used records when configured memory limits are reached.
Memcached Binary/Text Protocol Operations
# High-throughput key set with 3600-second expiration
set session:user:4092 0 3600 24
{"role":"admin","v":1}
STORED

# Microsecond point retrieval
get session:user:4092
VALUE session:user:4092 0 24
{"role":"admin","v":1}
END

# Atomic increment (rate limiting / metrics counters)
incr api_hits:tenant_10 1
Sweet Spot: Alleviating database query load, volatile web page fragment caching, session caches
Superpowers:
  • + Multi-threaded architecture scales cleanly across modern high-core CPU servers
  • + Slab allocator eliminates memory fragmentation under heavy volatile key churn
  • + Extremely simple, reliable protocol with zero bloat or operational complexity
Architectural Constraints:
  • - Does not support data structures beyond raw strings/bytes (unlike Redis)
  • - Zero disk persistence: data is completely wiped if the server restarts or crashes
Official Docs & Spec
Memgraph architecture blueprint
In-Memory Graph Database

Memgraph

2016
Pioneered by: Dominik Tomicevic & Marko Budiselic

Memgraph is an open-source, in-memory graph database built in C++ for real-time streaming analytics. Engineered as a high-performance alternative to Neo4j, Memgraph connects directly to streaming platforms like Apache Kafka and Redpanda, running complex Cypher graph pattern matching, network analysis, and fraud detection algorithms in sub-milliseconds on live event data.

Storage Engine:In-Memory C++ Native Graph Storage
Storage Model:Labeled Property Graph (LPG) in RAM
Query Interface:openCypher Query Language
Concurrency:ACID Compliant (Multi-Version Concurrency Control)
ACID & Consistency:Full ACID transactions (Snapshot Isolation and Serializable MVCC)
P99 Latency Profile:< 1ms in-memory graph traversals in C++
Architectural Highlights & Internals:
  • In-Memory Performance in C++: Delivers microsecond query latencies and up to 100x faster graph traversals than disk-bound alternatives.
  • openCypher Compatibility: Fully compatible with openCypher query syntax, enabling seamless migration from Neo4j applications.
  • Native Kafka/Redpanda Streams: Attaches directly to streaming message brokers to execute graph algorithms on in-flight data.
  • MAGE Graph Algorithms: Memgraph Advanced Graph Extensions library provides real-time community detection, PageRank, and link prediction.
Real-Time Streaming Cypher Query
-- Connect Memgraph directly to live Kafka fraud event stream
CREATE KAFKA STREAM financial_stream 
TOPICS transaction_events 
TRANSFORM fraud_detection_module;

-- Detect real-time suspicious fund transfers across network
MATCH (sender:Account)-[t:TRANSACTION]->(receiver:Account)
WHERE t.amount > 50000 AND sender.risk_score > 0.85
CREATE (sender)-[:FLAGGED_FOR_AUDIT {timestamp: localDateTime()}]->(receiver);
Sweet Spot: Real-time fraud detection, live cybersecurity network intrusion detection, dynamic logistics routing
Superpowers:
  • + Native C++ in-memory graph storage delivers up to 100x faster traversals than disk graphs
  • + Full openCypher language compatibility allows seamless drop-in replacement for Neo4j
  • + Built-in streaming connectors directly attach to Apache Kafka and Redpanda topics
Architectural Constraints:
  • - Entire active graph topology must fit comfortably within physical server RAM
  • - Higher RAM cost per gigabyte of data compared to disk-based graph stores
Official Docs & Spec
InfluxDB architecture blueprint
Time-Series Database (TSDB)

InfluxDB

2013
Pioneered by: Paul Dix & InfluxData

InfluxDB is an open-source time-series database optimized for storing and querying timestamped data, such as DevOps monitoring metrics, IoT sensor data, and application telemetry. Re-architected in version 3.0 on top of the Apache Arrow ecosystem and Rust DataFusion, InfluxDB offers limitless series cardinality, native SQL querying, and compact Parquet disk storage.

Storage Engine:Apache Arrow DataFusion + Parquet (InfluxDB 3.0 Engine)
Storage Model:Columnar Time-Series (Arrow / Parquet)
Query Interface:SQL & InfluxQL
Concurrency:Multi-Threaded Vectorized Execution
ACID & Consistency:Eventual consistency across Parquet files; atomic buffer writes
P99 Latency Profile:2-10ms high-throughput time-series queries and ingestion
Architectural Highlights & Internals:
  • Apache Arrow & Parquet Foundation: InfluxDB 3.0 leverages Apache Arrow in-memory tables and Parquet files for industry-standard columnar speed.
  • Unlimited High-Cardinality Metrics: Overcomes historical cardinality limitations, handling millions of unique tag combinations effortlessly.
  • Standard SQL Interface: Query time-series telemetry using familiar SQL dialect, eliminating proprietary query language learning curves.
  • DevOps & IoT Telemetry Standard: Integrates seamlessly with Grafana, Telegraf agents, Prometheus, and OpenTelemetry instrumentation.
InfluxDB 3.0 Standard SQL Telemetry
-- Query high-cardinality IoT sensor fleet using standard SQL
SELECT 
    date_bin(INTERVAL '15 minutes', time) AS time_window,
    device_model,
    location_id,
    AVG(voltage) AS avg_voltage,
    MAX(temperature) AS max_temp
FROM "iot_sensors"
WHERE time >= NOW() - INTERVAL '24 hours'
  AND firmware_version = 'v2.4.1'
GROUP BY time_window, device_model, location_id
ORDER BY time_window DESC;
Sweet Spot: IoT sensor telemetry, DevOps server metrics, real-time energy grid monitoring, Grafana dashboards
Superpowers:
  • + Re-engineered InfluxDB 3.0 built on Apache Arrow DataFusion and Parquet for industry-standard speed
  • + Solves high-cardinality bottlenecks: handles millions of unique series tags without memory spikes
  • + Query telemetry using standard ANSI SQL instead of legacy proprietary query languages
Architectural Constraints:
  • - Historical migration differences between InfluxDB 1.x (Flux), 2.x, and 3.0 (Arrow/SQL)
  • - Not designed for transactional OLTP workloads or relational schema foreign keys
Official Docs & Spec
MariaDB architecture blueprint
Relational DBMS (OLTP / Hybrid)

MariaDB

2009
Pioneered by: Michael Monty Widenius & MariaDB Foundation

MariaDB is a community-developed, commercially supported fork of MySQL, created by MySQL's original lead developer after Sun Microsystems was acquired by Oracle. Built to ensure a perpetual open-source future for the MySQL ecosystem, MariaDB introduces advanced storage engines like ColumnStore for analytics, the crash-safe Aria engine, temporal tables, and high-performance thread pooling.

Storage Engine:InnoDB, Aria, ColumnStore, Spider, MyRocks
Storage Model:Row-Oriented & Columnar (Multi-Engine)
Query Interface:SQL
Concurrency:Row-Level Locking & Thread Pool
ACID & Consistency:Full ACID (InnoDB & Aria engines with crash-safe transaction logs)
P99 Latency Profile:1-3ms OLTP point read/write using InnoDB or Aria
Architectural Highlights & Internals:
  • Guaranteed Open-Source Freedom: Governed by the non-profit MariaDB Foundation to ensure true community stewardship.
  • ColumnStore for Big Data: Plug-in columnar storage engine transforms standard MariaDB servers into distributed analytical platforms.
  • High-Performance Thread Pool: Handles tens of thousands of concurrent client connections without connection starvation.
  • Drop-in MySQL Compatibility: Matches MySQL wire protocols, configuration flags, client drivers, and schema semantics.
MariaDB Temporal Tables & ColumnStore
-- System-versioned temporal table tracks entire history automatically
CREATE TABLE employee_salaries (
    emp_id INT NOT NULL,
    salary DECIMAL(10, 2) NOT NULL,
    department VARCHAR(50) NOT NULL,
    PRIMARY KEY (emp_id)
) WITH SYSTEM VERSIONING;

-- Query employee salary as it was at a specific historical point in time
SELECT * FROM employee_salaries 
FOR SYSTEM_TIME AS OF '2025-01-01 00:00:00'
WHERE emp_id = 42;
Sweet Spot: Mission-critical LAMP stacks, enterprise ERP, high-availability WordPress/Drupal, distributed analytics
Superpowers:
  • + True non-profit open-source stewardship ensuring independence from Oracle governance
  • + Multi-engine modularity: InnoDB for OLTP, ColumnStore for analytical big data, Aria for temporary tables
  • + Galera Cluster provides synchronous multi-master replication with automatic node provisioning
Architectural Constraints:
  • - Syntax diverges from latest MySQL 8.0 features (e.g., differences in JSON and GIS functions)
  • - Maintaining multiple storage engines within one cluster increases administrative complexity
Official Docs & Spec

No databases matched your search or filter query.

© 2026 Guilherme's Hub • Open Code, Open Mind 🚀