Database startup is rarely one binary moment.
After a crash or cold start, different capabilities become safe at different times.
LioranDB models this explicitly through progressive readiness states.
Startup states
The DBMS can move through states such as:
OPENING
RECOVERING
INDEX_REPLAYING
READ_DEGRADED
READ_READY
FINALIZING
WRITE_READY
CORRUPT
This is more informative than a single Boolean called ready.
Different kinds of readiness
LioranDB separately tracks whether it can:
- Serve primary-key reads
- Serve indexed reads
- Accept degraded writes
- Accept fully ready writes
- Query through an index replay overlay
- Declare all background state drained
For example, primary documents may already be recoverable while secondary indexes are still replaying mutations.
In that situation, refusing every read may be unnecessarily conservative.
But allowing an index query would return incomplete results.
Capability gates
The engine checks facts such as:
Primary recovery complete
Catalog loaded
Logical primary view ready
Manifest valid
WAL replay complete
Secondary index ready
Text index ready
If a capability is blocked, the readiness report records the reasons.
That makes startup behaviour observable and testable.
Timelines and metrics
LioranDB records timestamps for events such as:
- API handle creation
- Primary recovery
- Catalog readiness
- WAL replay completion
- Index overlay availability
- Secondary readiness
- Text readiness
- Full write readiness
It also tracks rejected operations before each capability becomes safe.
Why this architecture matters
Large databases can take meaningful time to rebuild indexes or drain recovery work.
A progressive readiness model allows a service to expose safe functionality earlier without pretending the whole system is ready.
The important word is safe.
Fast startup should not mean returning subtly incomplete data.
It should mean identifying the earliest point at which each operation becomes correct.
LioranDB is created by Swaraj Puppalwar at Lioran Group.
Links:
Top comments (0)