A clear direction
for your data.
Familiar queries above. A thoughtful engine below. ShiverDB brings stable records, an ordered history of change, and a SQL-inspired language into one database design.
ShiverDB is at the specification stage. This is a look at the system we want to build.
Less to work around.
More to build on.
A database should handle the mechanical work without hiding what your program means. Three ideas keep this design grounded.
Records that stay themselves.
A record's identity does not depend on its place on disk. Move it, compact it, or add a new version. References still point to the same record.
Understand stable identity
Change with a common thread.
An authoritative commit log gives changes a durable order. The same history can support recovery, changefeeds, and the results your application follows.
Follow a commit
Familiar, without the guesswork.
Start with tables and SQL-like queries. Reach for routines, record references, or subscriptions when you need them. Advanced features stay optional.
Find your bearingsYou already know
where to start.
A table. A filter. A result. ShiverDB starts with a relational model you can recognize, then makes important choices explicit.
Named parameters carry input. Record references connect data. Missing values use unknown, never a quiet substitution with zero.
select
id,
name,
level
from player
where level >= :minimum_level
order by level desc, id asc
limit 50Illustrative syntax from the language specification. Not a live query.
A steady current underneath.
The proposed write path puts durable history first. A transaction produces changes, the engine records them, and committed state becomes visible in order.
- 01Prepare the command
- 02Decide the changes
- 03Durably record
- 04Publish the commit
There is more below the surface.
Read the ideas, their boundaries, and the specifications behind them.