The project is not trying to compete with SQLite. It is a learning and systems-design project: what happens when you build the parts of a small database yourself?

Design philosophy

The most important choice is simplicity. TegDB uses a deliberately constrained architecture:

• embedded engine
• single-process access
• write-ahead logging
• crash recovery
• B+tree-style indexing
• schema and constraint checks
• SQL-like query surface

Avoiding broad concurrency is not a weakness for this kind of project. It reduces the number of failure modes and makes the storage path easier to reason about.

Why build a database

Database internals are easier to understand when you have to implement the boring parts:

• how records are serialized
• how pages are found
• how an index points to storage
• when a transaction becomes durable
• how recovery decides what to replay
• how a query stops early with LIMIT

Reading database code is useful. Writing a small one makes the tradeoffs harder to ignore.

Reliability work

The most interesting code in a database is often not the happy path. TegDB spends attention on:

• write-ahead log commit markers
• rollback behavior
• partial write handling
• file locking
• recovery after crash
• corruption boundaries

These are the parts that turn “data structure on disk” into “database.”

What I learned

The database abstraction is expensive because it hides many coordinated guarantees. Even a small embedded engine has to care about durability, serialization, schema behavior, query planning shortcuts, and operational failure.

The lesson is not that every app should have a custom database. The lesson is the opposite: after building even a small one, you gain more respect for mature storage engines.

Open source status

TegDB is public because the project is mainly educational and architectural. It is useful as a record of experiments in storage design, not as a claim that it should replace established embedded databases.