LioranDB V2 is now publicly available in pre-alpha, and I want developers to do something slightly unusual:
Try to break it.
Not just install it, run insertOne(), see that it works, and close the terminal.
Push it.
Give it weird queries. Throw large datasets at it. Create indexes. Delete things. Restart the server. Send concurrent requests. Test edge cases. Try workflows I probably didn't think about.
If something behaves strangely, becomes painfully slow, crashes, returns an unexpected result, or simply feels bad to use, I want to know.
What is LioranDB?
LioranDB is a developer-first document database being developed in India.
V2 is written in Rust and currently includes things such as:
- B+ Tree primary storage
- MVCC
- Write-Ahead Logging
- Checkpoints and crash recovery
- Secondary indexes
- Full-text indexing
- Docker deployment
- TypeScript/JavaScript driver
- MongoDB-style document APIs
The goal isn't to pretend that a pre-alpha database is already production-ready.
The goal is to find everything that's wrong with it before it gets there.
So, I'm Looking for Feedback
I'm especially interested in hearing about:
🐛 Bugs
Anything that crashes, hangs, produces incorrect results, corrupts state, or behaves differently from what you'd expect.
⚡ Performance problems
Slow queries, unexpected latency, bad scaling with larger collections, inefficient indexes, memory problems, or operations that become suspiciously expensive.
🧪 Edge cases
Strange documents. Strange queries. Strange sequences of operations.
Basically, be creative.
Databases tend to behave nicely until somebody does something the database author never imagined.
Be that somebody.
🧑💻 Developer experience
I'd also love feedback about the API itself.
Is something confusing?
Does an error message suck?
Is an operation unnecessarily complicated?
Did you have to read the documentation three times to understand something?
That's a bug too, just wearing nicer clothes.
How to Test It
Start here:
Documentation:
https://docs.liorandb.com
LioranDB:
https://liorandb.com
The documentation contains the setup instructions and APIs needed to start experimenting with LioranDB.
You don't need to build a serious application.
Create a test project, generate some data, connect the driver, and start attacking it.
Try things like:
- thousands or millions of documents
- concurrent reads and writes
- secondary indexes
- text search
- pagination
- large
limit()values - unusual filters
- sorting
- aggregations
- repeated updates and deletes
- restarting LioranDB during workloads
- crash/recovery scenarios
- combinations of operations that look suspicious
If you manage to make LioranDB unhappy, congratulations.
That's exactly what I'm looking for.
Found Something?
Send me what happened at:
If possible, include:
- what you were trying to do
- the query/code you ran
- what you expected
- what actually happened
- dataset size
- logs or error messages
- your OS/environment
- reproduction steps
Even if you're unsure whether something is technically a bug, send it.
Performance observations, confusing APIs, documentation problems, missing features, architectural criticism, and general feedback are all useful.
Why I'm Doing This
A database isn't validated because its benchmark graph looks pretty.
It's validated when people outside the project start doing things the original developer didn't anticipate.
LioranDB V2 is still pre-alpha.
There are going to be bugs.
There are going to be slow paths.
There are probably wonderfully cursed combinations of operations waiting somewhere in the engine.
I'd rather developers discover them now than users discover them later.
So install LioranDB.
Build something stupid with it.
Stress it.
Abuse the API.
And please, try to break my database.
Feedback: feedback@liorandb.com
This article was originally published by DEV Community and written by Swaraj Puppalwar.
Read original article on DEV Community