stonebraker_skill

This skill guides database architecture design inspired by Stonebraker, emphasizing workload-specific, shared-nothing, and durable, extensible storage and

Python

3

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill copyleftdev/sk1llz --skill stonebraker

SKILL.md8.8 KB

Overview

This skill captures Michael Stonebraker’s database-architecture philosophy and patterns for designing durable, high-performance data systems. It emphasizes workload-specific architectures, clean component separation, and pragmatic trade-offs between OLTP and OLAP. Use it to guide fundamental decisions about storage engines, replication, and system decomposition.

How this skill works

The skill inspects workload characteristics (latency, throughput, access patterns, durability requirements) and recommends architecture patterns: main-memory OLTP partitions, columnar OLAP stores, shared-nothing scaling, and write-ahead logging as the durability backbone. It maps design choices to implementation primitives (buffer manager, WAL, execution model, storage format) and produces actionable guidance for internals, storage engines, and system APIs.

When to use it

Designing a new storage engine or database product
Choosing OLTP vs OLAP architectures for a system
Evaluating trade-offs for partitioning, replication, and durability
Refactoring a monolithic DB into specialized subsystems
Defining extensibility points (types, operators, indexes)

Best practices

Start with the workload: optimize for the common case, not theoretical generality
Separate concerns: SQL interface, planner, executor, access methods, storage manager, and WAL
Prefer specialized engines: row-oriented in-memory for OLTP, columnar for analytics
Treat the log as ground truth: append before applying changes and design recovery from it
Design shared-nothing partitioning to avoid cross-node contention; favor deterministic execution for replication

Example use cases

Design an in-memory OLTP partitioned engine with single-threaded partitions and stored procedures
Specify a columnar analytics engine with projections, heavy compression, and read-optimized stores
Choose WAL layout and recovery flow for a new storage manager implementation
Plan a migration from a combined OLTP/OLAP deployment to separate specialized systems
Define an extensible type/operator API modeled on Postgres for custom data types

FAQ

Choose row storage for point updates and high-concurrency OLTP. Choose columnar storage for scan-heavy analytics, compression, and vectorized aggregation workloads.

Is shared-nothing always better than shared-disk?

Shared-nothing typically scales more predictably for horizontal growth and avoids coordination overhead. Shared-disk can simplify deployment but often becomes a scalability bottleneck for large workloads.