Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What to choose badgerhold and bolthold #113

Open
llgcode opened this issue Oct 24, 2024 · 2 comments
Open

What to choose badgerhold and bolthold #113

llgcode opened this issue Oct 24, 2024 · 2 comments

Comments

@llgcode
Copy link

llgcode commented Oct 24, 2024

Hi,
and thanks to share your work.
Your 2 packages feel really cool,

So which one should I use, it feels that badger is better in terms of performance and maintenance over bolt.

But I also really like boltholdSliceIndex that I didn't find in badgerhold. Why it was not implemented in badgerhold?

Thanks for your help

@timshannon
Copy link
Owner

My personal preference is BoltHold. It's more simple and straightforward, and I've run into less issues with it, but you are correct that it generally performs slower than Badger. However if your goal is performance or you are dealing with large datasets, then my recommendation will always be SQLite.

The entire goal of creating Bolthold was to have something that still had good performance, but was primarily easy to use. It's goal was to compete with writing your application state to text files, not necessarily replacing an entire DBMS.

I wrote a quite blog post a long time ago comparing them: https://tech.townsourced.com/post/boltdb-vs-badger/

@llgcode
Copy link
Author

llgcode commented Oct 25, 2024

Hi Tim,
thanks for your answer. I think for my purpose every solution feels adapted, I don't have today a lot of performance constraint. And for a website that manage media and page content for some users (not much), it could do the trick very well.
I'll read your post

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants