Hive: The future of Hive

[leisim]

TLDR: Hive 2.0 will be rewritten in Rust to get amazing performance, multithreaded queries, read and write transactions, and super low memory usage. The code will work 1:1 in the browser.

Situation

I have thought a long time how to correctly implement queries in Hive and I have come to the conclusion that it is not possible with the current architecture.
I have reviewed many projects on GitHub which use Hive and most of them have to create their own suboptimal workaround for queries.
Apart from queries, Hive has another problem: Dart objects use much RAM. Since Hive currently keeps at least the keys in RAM, you can hit the OS limit of mobile devices quite fast.

I also created polls some time ago on the Hive documentation page and there were two very strong takeaways:

1. Queries are something almost every user wants
2. An overwhelming majority (86%) of users don't mind breaking changes

Idea

So here is what I have come up with:
I will completely rewrite Hive in Rust. I will use the strengths of the old implementation (like auto migration) and fix the issues.
On the VM, Hive will use LMDB as backend and on the Browser IndexedDB. The VM implementation will provide the same features as IndexedDB to allow easy code sharing.
The two main goals of Hive will stay the same: Simplicity and Performance.

I have a small prototype and the performance is amazing. LMDB has to be some kind of black magic.

Sample

Here is how it is going to work:

The model definition is very similar to current models:

@HiveType(typeId: 0)
class Person {
  @Primary
  int id;

  @HiveField(fieldId: 0)
  @Index(unique: false)
  String name;

  @HiveField(fieldId: 1)
  int age;
}

Hive will then generate extension methods so you can write the following query:

var box = Hive.openBox<Person>('persons');
box
  .query()
  .where()
  .nameEquals('David')
  .or()
  .nameStartsWith('Lu')
  .filter()
  .ageBetween(18, 50)
  .sortedByAge()

where() vs filter()

The difference between where() and filter() is that where() uses an index and filter() needs to test each of the resulting elements. Normally a database figures out when to use an index itself but Hive will provide you the option to customize.

There are multiple reasons for that:

1. This code will work 1:1 with IndexedDB
2. You know your data best and can choose the perfect index
3. The database code will be significantly easier

Things to figure out

• How can auto-updating queries be implemented efficiently?
• What are the restrictions for shipping binaries on iOS?
• Should there still be a key-value store?

Blocking Issues (pls upvote)

• dart-lang/sdk#37022
• dart-lang/sdk#37355
• flutter/flutter#46887

Other issues

• WebAssembly/reference-types#61

For existing apps using Hive 1.x:

I will continue to keep a Hive 1.x branch for bugfixes etc.

What do you think?

[kaboc]

Rewriting in Rust sounds so interesting. Better performance and less memory usage are attractive and welcome.

However, I'm seriously worried about compatibility of Box. Can boxes for v1.x still be used in v2 as well? It's dubious as to what other users actually meant in the polls. For me, only breaking changes of APIs are acceptable, not of Box.

I have to decide whether to leave Hive and choose another package for the app I'm currently developing if there is a risk that I need to go through all the trouble to port old boxes to new ones on my own sometime in the future.

Having said that, your plan is exciting too all the same. I look forward to seeing the first release of the new major version.

[leisim]

Yes I agree. It is bad that old boxes will not be compatible and existing apps in production cannot upgrade to the new version without loosing their data.

Hive is very young and I still think it is the right path. For future breaking changes there will be auto migration. Unfortunately that is not possible for this change because we switch the backend.

[shinayser]

A noob question: how will you make Rust to work with Dart?

[leisim]

Using Dart FFI

[shinayser]

Using Dart FFI

But DART FFI is only for C language, not Rust, right?

It will require the user to use FFI or are you planning to provide a working interface already in Dart?

[leisim]

But DART FFI is only for C language, not Rust, right?

Rust does provide C interop...

It will require the user to use FFI or are you planning to provide a working interface already in Dart?

The user will only use Dart and does not even notice the Rust backend.

[Mravuri96]

You should give https://vlang.io/ a shot 😜

[leisim]

You should give https://vlang.io/ a shot

V is interesting but in my opinion, there are multiple reasons why it is not a good idea to use V at the moment:

• V still very unstable
• V has a very small community and not many packages
• V is a very "basic" language. While the creator argues that this is a design choice, I expect languages to provide at least a Set data structure.
• I think Rust is superior to V in almost any aspect. There are many zero-cost abstractions like iterators

[marcelgarus]

What initially excited me about Hive is that it's a pure Dart library without external dependencies, so it runs everywhere.
Obviously, the same is true if the backend would be implemented in Rust, but I begin to wonder: There are loads of existing database implementations in Rust that are far more advanced. There are of course the usual SQLite-ish standards, but also document-based databases like MongoDB and truly innovative approaches like this one.
I'm afraid there's nothing about Hive that's fundamentally better than with other database solutions, so rather than reimplementing the wheel, why not use some existing database and built a nice Dart-wrapper around it? Because developers also use the Rust database on its own, there are more users, more contributors and all developers from both the Rust and the Flutter community benefit from the research, optimizations, and bug fixes that are implemented on the Rust side.
This package could simply focus on providing the most intuitive Dart API possible, which would make maintaining the package easier as well.

[leisim]

What initially excited me about Hive is that it's a pure Dart library without external dependencies

Yes, that was the goal but it turned out that most users don't want a database that is basically an in-memory KV-store. The problem with Dart is that it is kind of slow, its objects are rather memory hungry and it misses essential features to implement a more advanced database.

There are loads of existing database implementations in Rust that are far more advanced

I thought the same thing but the list of candidates is short. In fact, I didn't find a single database that is suitable for mobile devices and our requirements.

Also, to my knowledge, there is no database that is built as a counterpart to IndexedDB. It is not trivial to write a database that works exactly the same in the browser. IndexedDB is very different from most other databases.

I'm afraid there's nothing about Hive that's fundamentally better than with other database solutions

As I said, I don't think there exists a single cross-platform database that also works in the browser and I don't think existing databases can be easily used with Dart and still have great performance. Realm, for example, will never work with Dart because it relies on proxy objects.

So I'm writing basically writing an abstraction around IndexedDB and LMDB in Rust which can be compiled to a binary or WASM.

And then there will be the Dart wrapper around this "backend".

It should be easily possible to use only the Rust side for example with React native.

Edit: I already have a fully working prototype of the LMDB part of the wrapper and not much Rust code is required. The performance is exceptional.

If you have an alternative approach that allows us to have a "real" database which also works in the browser, I'd love to discuss it.

Edit2: Another advantage of this approach is that breaking changes of the binary format will no longer be required and bugs that corrupt the database will not happen anymore because the storing of the data will be handled by LMDB and IndexedDB respectively.

Edit3: Like most other databases, Noria, the one you linked, is for backends and thus not really suitable for mobile devices.

[marcelgarus]

Okay, I see. I was really expecting more lightweight Rust databases to exist.
Then I take back what I said before — the Rust-Dart-architecture seems to be a great fit 😊
I'm looking forward to using this

[leisim]

There is one topic where I still need input: Since we are rebuilding Hive anyway, I'd like to make it ready for synchronization from the beginning.

What do you guys think about CouchDB as a backend?
Do you know good articles or papers on sync without conflicts? I need an easy to use (for the user) mechanism to avoid or resolve conflicts.

[ashim-k-saha]

Syncing with CouchDB, is exactly what I am looking for my next project.

PouchDB, implementation in dart will be great solution.

[frank06]

Used CouchDB a long time ago, and while the conflict resolution mechanism was neat, queries were a pain. That might have changed, or not. I thought one of the major drivers of this Hive rewrite was query support.

[leisim]

I thought one of the major drivers of this Hive rewrite was query support.

Yes, the queries you use with should be more or less independent of CouchDB.

CouchDB is just an idea and nothing I have decided yet. I just want to figure this out before the first stable release of the new version has been released.

It would be great if someone knows a backend which fits our use case.

[jamesdixon]

Unsolicited advice / thought:

I realize you're planning for the future ahead of time by factoring in sync support, but it's a complex
topic and something I personally would leave till after the rewrite 😄

I also say this because I'm not using CouchDB and while I'd love conflict resolution, I haven't found any really easy way to sync CouchDB changes to Postgres. This seems to be a problem for many who may use another database. Limited research, but I just wanted to throw it out there given that my anecdotal evidence suggests that more people are using Postgres/MySQL/etc and if CouchDB support for those is weak, it may not be worth the additional effort upfront.

All that said, killer job with Hive thus far. Excited to see what's next.

[leisim]

Thanks for your opinion. Yes it would be cool to have a conflict resolution which is independent of the backend database but I have to do a lot of research because I have no idea how to do it 😆

[jonataslaw]

I think it would be prudent to create a second project> Hive ffi I feel very enthusiastic to test Hive with Rust, it must be incredible, however, in my opinion, changing the backend is not legal for a stable library, if it were pre-release it would be justified, but there are many people who use Hive as a KV storage for many scripts than SP does not do so well, and queries are legal, but even cooler than that would be to maintain compatibility.
I'm following the thread because if Hive changes, maybe I will need to fork this project, but if there is a risk-free way of migration, I fully support the idea.

[leisim]

I don't think it will be possible to automatically migrate the data because the two models are not entirely compatible. But I will maintain a branch that contains the current version so you can just continue to use it.

[algodave]

@leisim In your vision, will the new Hive still allow to Create adapter manually? I'm not using code generation In my project, I'm just defining my own class MyModelHiveAdapter extends TypeAdapter<MyModel>

[MahdiPishguy]

when this version can be release and we can use that? :dancer: :dancer: :dancer:

[leisim]

In your vision, will the new Hive still allow to Create adapter manually?

@algodave I don't think it will be possible in the same way as it is currently because in order to query your data, Hive needs to understand its structure. Probably there will still be adapters that map objects to Map<int, dynamic>. The keys of this map will be the field ids and the values are the primitive values of the fields (int, double, bool, String, List<int>, List<double>, List<bool>, List<String>). You can customize these adapters.

when this version can be release and we can use that?

@MahdiPishguy It probably still takes another month until I have the first test version.

[Xylobol]

@jonataslaw

I'm following the thread because if Hive changes, maybe I will need to fork this project, but if there is a risk-free way of migration, I fully support the idea.

I've been working on a mission-critical project with Hive, and a major pull was that it's completely written in Dart, so I may need to fork as well. If you're interested, I can keep you posted.

[stefanrusek]

Might I request you create a new library? A complete rewrite, with different behavior, and large api changes is not a new version but a new library. Going down this path means there will be numerous forks of Hive 1, and people would just be better served if you started a new project and let Hive continue to evolve.

[algodave]

@Xylobol @jonataslaw I am one of those who would be interested in a fork

[listepo]

@leisim any news?

[stevenspiel]

@leisim I'm also interested in the progress on this.

[wbsantos]

I'm writing an app in flutter and thinking about use ArangoDB at the backend.

I don't know if it is the best solution for what you are thinking, but maybe you can keep it on the list of possible databases to autosync hive.

ArangoDb is a multi paradigm database, it can be document, graph or key-value. I'm not sure if it fits the hivedb structure, but it is a feature rich platform you may consider.

[frank06]

I'm also really interested in the state of Hive 2.0.

I recently open sourced Flutter Data which uses Hive at its core. I wanted to start working on improving performance, but is that worth the effort if 2.0 is near?

In addition, @leisim I was wondering what you think about FD's Relationships API and if it could somehow be integrated back into Hive 2.0's Dart/Flutter layer.

[marcelgarus]

@frank06 Interesting, I was working on a similar pattern for our Schul-Cloud app. I published the package as hive_cache. Similarly to flutter_data, it tries to model the relationship between entities and takes care of fetching data when necessary. The package provides Entitys, Collections, and Connections for that along with builders. I'd love it if Hive would integrate some common functionality natively.

Also, because Hive 2.0 will run with Rust at its core, there will be a simple-to-use Rust API anyway, so why not use it to run a webserver when the app is running in debug mode? Similarly to how Dart DevTools work, Hive could also provide a webpage with live preview and editing capabilities for the app, making debugging much easier.

[frank06]

@marcelgarus Very interesting! I was totally unaware of hive_cache. Nice work! Definitely will check it out in more detail.

It would indeed be great to have a common API for Hive relationships (that our projects could extend to use with their own naming). I started from scratch because, while Hive had HiveLists, it didn't have an owner/inverse mechanism for to-one/belongs-to type relationships when I needed them.

[britannio]

I just want a blazingly fast cross-platform key-value store, maybe that could be maintained in a separate package?

[TheMisir]

+1 @britannio. I just want to save small key-value structured data. If I would like to store large datasets I would be probably using sqlite database.

I know this package is pretty new but lot's of projects already implemented hive v1 which is currently broken (have some dependency hell issues).

[stefanrusek]

+1 @britannio @TheMisir I agree. I need real DB then I reach for cloud firestore.

[jonataslaw]

+1 In fact I use Hive as a simple database, storing Key value, and objects. I don't need functions like advanced queries, and Hive serves me well.
If there was a version with FFI, I would use it in future projects maybe, but for my current projects, Hive looks great.
I still think that Hive should continue to dart, and that there was a second package like Hive-ffi to use Hive-ffi, I believe that would please 100% of the users who are here, both those who will follow with Hive using dart, and the who will follow with Hive using Rust, but in the end, it is leisim who chooses the direction this will take.

[2x2xplz]

@britannio for cross-platform maybe check out ObjectBox?

[TheMisir]

@2x2xplz I did used ObjectBox on native project (written in pure java not flutter). Sometimes it crashes unexpectedly. I don't know I might be did something wrong, but I'm sure I did everything said in documentation. But hive.db works like a charm (ps: currently broken if you're not on the stable channel).

[neckaros]

+1 @britannio. I just want to save small key-value structured data. If I would like to store large datasets I would be probably using sqlite database.

I know this package is pretty new but lot's of projects already implemented hive v1 which is currently broken (have some dependency hell issues).

The problem is that fsqlite does not work on web

[jonataslaw]

Off-topic: Guys, does anyone know if leisim (creator of Hive) is okay? He lives in one of the Corona Virus epicenters and he disappeared, his last comment was in this post a few months ago.

[yringler]

@leisim wrote

...and existing apps in production cannot upgrade to the new version without loosing their data.

This was one of the major causes of concern on this thread.

@leisim, is it very difficult to continue supporting just reading from old style boxes?
That would allow

1. iterating through the
2. adding item to new style box
3. Verify that all data was copied over correctly
   3.1 This would require that people override the equality operator.
4. delete legacy box

which could be wrapped up in a method and shipped with the hive package. To migrate data, a possible API shape would maybe be something like this:

if (Hive.legacyBoxExists("userdata") {
  final legacyBox = Hive.openTransitionalBox<UserData>("userdata");
  await legacyBox.migrateData();

  if (await legacyBox.verify()) {
    await legacyBox.removeFromDisk();
  }
}

Or verify and removeFromDisk could be collapsed into migrateData.

_Edit:_ Even better, a parameter in openBox , { bool migrate }, which would then run the migration.

[OlegBezr]

@leisim
Hey! So when should we expect the new version of Hive?

[mdrideout]

Hey @leisim , just continuing to support the idea that you build the new database as a brand new library. Hive DB 1.0 in its current form perfectly fulfills my needs. I would love to continue using it without worrying about weird dependency stuff.

A new name and a new library for a fundamentally different database I think is very appropriate.

I have spent a ton of time on a production app that uses Hive DB, and it would be very expensive for me to need to rewrite all of the data management to support a library, and deal with my client apps update processes.

I'm sure you will find that the open source community is happy to help maintain hive 1.0 as its own library

[mdrideout]

Off-topic: Guys, does anyone know if leisim (creator of Hive) is okay? He lives in one of the Corona Virus epicenters and he disappeared, his last comment was in this post a few months ago.

I noticed on LinkedIn that he started a new job around the same time he stopped updating Hive. New job looks very cool, could be very demanding. He may need more community support support for Hive.

[frank06]

It's clear that Simon owes us ZERO. He put out an outstanding library that makes our developer lives better.

As an open source maintainer myself, I wouldn't leave users of my library in the dark even if I had a very demanding job.

"Hi all, I apologize for my delayed response. I'm doing well, thanks for worrying about me! I have a very demanding job and don't have time to think about how to move forward with Hive. I'll be in touch as soon as anything changes. Thank you!"

Takes literally one minute.

Being sick is a completely different story.

[leisim]

Hey guys,
Thanks a lot for your patience and kind words. I'm very sorry for the late response but the last months have been a bit crazy for me and I had zero time for open source work. I hope I can address some of your questions. If I miss some of them, please ask me again ;)

Hive could also provide a webpage with live preview and editing capabilities for the app, making debugging much easier.

@marcelgarus Yes, making debugging easier is one of the goals of the new version.

I've been working on a mission-critical project with Hive, and a major pull was that it's completely written in Dart, so I may need to fork as well. If you're interested, I can keep you posted.

@Xylobol @stefanrusek @jonataslaw I hear all of you and I think it is a good idea to maintain both, the new and "old" version because their purpose does not overlap 100%. I have not decided the best way to do it however. Maybe the new version should move to another repo or we keep the old one as a branch. I might also need some help to maintain both versions but I'm sure we can solve that.

is it very difficult to continue supporting just reading from old style boxes?

@yringler I'm not sure whether this is a good idea. It would require a lot of work. Depending on your needs, maybe we can create a migration version. Since the new version will work a bit different, not everything can be migrated however.

Hey! So when should we expect the new version of Hive?

Due to my limited time, the release is not in sight yet. I would guess it takes at least another few months. It looks like I have a bit more time now and development should speed up now.

A new name and a new library for a fundamentally different database I think is very appropriate.

I'm not sure. I see the pros for creating a new project but I think the new database will be very cool and it would be sad if the old "Hive" would be popular while the new version has only few users due to its bad pub.dev popularity score...

I noticed on LinkedIn that he started a new job around the same time he stopped updating Hive. New job looks very cool, could be very demanding. He may need more community support support for Hive.

@mdrideout Yes my job at BMW and my studies are partly to blame for my little free time in the last months :(

As an open source maintainer myself, I wouldn't leave users of my library in the dark even if I had a very demanding job.

@frank06 Very sorry for that. I do feel responsible for all the people who depend on the project, despite Hive being open source.

Being sick is a completely different story.

I have been but I still should've posted an update.

[yringler]

I'm not sure. I see the pros for creating a new project but I think the new database will be very cool and it would be sad if the old "Hive" would be popular while the new version has only few users due to its bad pub.dev popularity score...

IMO there's no reason to be concerned about that. People will find it with search, and there could be a note in the readme to check out the new package - I think it will be very popular. People are quick to find great packages (like one I bumped into a while back, hivedb :wink: )

Case in point: @ryanheise made a package, just_audio, in a pretty competitive area - playing audio - and it quickly shot up to a very high score.

I totally get the concern - you already have an established, successful "brand", and to start all over is a daunting prospect. But I think it's a great idea, and with the huge benefits which may be realized in the new version - not having to worry about using up all the RAM, queries, crazy speed - maybe it's better to start fresh and see how far the rabbit hole goes.

Whatever you decide, I'll be looking forward to the new version.

[TheMisir]

What if there is a package (something like: hive_migrate) to migrate already exists data from hive-v1 to hive-v2 instead of doing this automatically. I don't think it would be hard thing.

1. List v1 boxes
2. Read data from v1 boxes
3. Save data to v2 boxes
4. Clean up (remove v1 boxes to free up unused space).

That's it. All of our data migrated to v2.

[leisim]

@TheMisir Yes this is a good idea but the new version will only support objects (not Maps, ints etc.) so they cannot be migrated. It would be very easy if we decided to create a new package for the new version because you could just import both and do the migration yourself.

[yringler]

not Maps, ints etc.

Meaning, it can store ints as part of objects, but not by themselves.
For example box.put('key', 4) would not be supported anymore.

[leisim]

@yringler exactly

[mdrideout]

I'm not sure. I see the pros for creating a new project but I think the new database will be very cool and it would be sad if the old "Hive" would be popular while the new version has only few users due to its bad pub.dev popularity score...

I wouldn't worry about the popularity score a lot as a decision maker on that, I have seen many similar plugins have high popularity scores. When you search "nosql database" on pub.dev, there are several options in the high 80's and 90's. I think they do a good job showing relevant options, and it seems more like relative popularity trends, rather than a fixed descending order of popularity.

If you do the rounds of getting it out there, having good docs and tutorials, it will pick up speed. The thing that attracted me to Hive was your high quality documentation. In comparison, Sembast's documentation is kind of lack luster and not nearly as newbie friendly.

[deadsoul44]

Here is my vote:

The new version should be a completely separate package with a new name. It will already benefit from the popularity of Hive. We will advertise it everywhere.

Hive should be maintained here.

Otherwise, it will be complete mess in the community. People will get confused whether if they are talking about v1 or v2 or vXXXX or sql based or nosql based, etc, etc, ....

[leisim]

@deadsoul44 I think you are right. I did not think about the countless upcoming questions about the two versions and which one to use. It will probably be easier with two packages.

I will probably need some help maintaining both packages.

[TheMisir]

@leisim I could help to maintain this version.

[AKushWarrior]

@leisim noticed you've archived a few Hive packages. Does that have anything to do with the new package?

[yringler]

This repo is now a mono repo, and hive_generator and hive_flutter where
moved into it in subfolders.

On Wed, Jun 24, 2020, 12:05 AM Aditya Kishore [e-mail]
wrote:

@leisim https://github.com/leisim noticed you've archived a few Hive
packages. Does that have anything to do with the new package?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/hivedb/hive/issues/246#issuecomment-648570388, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AA7B3KKKUODPEIF7HKOOIVDRYF3SLANCNFSM4K56YKVA
.

[leisim]

Just wanted to let you know that I made some progress regarding "Hive 2.0".

The new database will be called "Isar" and you can check out the current state at github.com/isar. Some parts are still missing to make it usable tho.

[mdrideout]

@leisim - have you looked into adding more maintainers for the old hive? I submitted a PR for a fix a few days ago that broke the generator on the latest version of flutter. https://github.com/hivedb/hive/issues/364

[leisim]

@mdrideout Not yet. Would you mind if I added you as one of the maintainers?

Who else has a little spare time? ;)

[AKushWarrior]

There's three sides to maintainership:

• project management
• bugfixing
• feature implementation

I have time for any of the three, but thought that I might point that searching for a specific category (as opposed to a broad "maintainer") might be more feasible.

[leisim]

@AKushWarrior

I would be interested in any of the three :+1:
Especially bug fixing and publishing new versions is required currently I think.

[yringler]

https://github.com/hivedb/hive/issues/246#issuecomment-636697140v

I could help to maintain this version.

@TheMisir , still up for it? Where you added as a maintainer?

[TheMisir]

@yringler yes, I could help to maintain hivedb.

[marcelgarus]

@leisim I'm also interested in maintaining, but mostly project management / issue triage.

[leisim]

@AKushWarrior @TheMisir @marcelgarus I invited you to the Hive organization. I hope I didn't forget anyone.

Also, I'd like to hear your guys options on isar/isar#2

[JagandeepBrar]

I would also be interested in helping maintain the project. I could help with bugfixing and issue triage, but would not have much time currently for feature implementation (but could change in the future!)

[TheMisir]

@leisim , how can we publish new versions to pub.dev? For example hive_generator and hive packages needs an update to fix dependency issues. Pub.dev latest version is currently unusable in latest flutter version due to those issues.

[JagandeepBrar]

@TheMisir He will need to add you as a contributor/member to the publisher on pub.dev. After that, you will be able to run dart pub publish.

[AKushWarrior]

Just pub publish is fine. No need for dart.

But yeah... We'd need publish permissions to be autonomous. Thoughts @leisim

[medmedmedic]

Super cool, slow queries are the limitation to build large apps in a flutter "Absolutely true". Waiting for Hive 2.0

[omidraha]

1. Can you give an estimate of when Hive 2.0 will be published with query [and sync] support ?
2. Can we use Hive 2.0 with flutter similar to hive_flutter for cross platform supporting in Android and IOS ?

[yringler]

@leisim, any timeline when new maintainers will be able to publish updates to hive to pub.dev?

[mdrideout]

Transitioning to SEMBAST

I just wanted to comment that over the last few weeks I have transitioned my projects away from hive, to using sembast database, freezed (a code generator that helps you deal with immutable objects, and also has built-in support for json_serializable). It was a really difficult decision because I like HIVE, but the idea of maintenance and support getting even worse as @leisim focuses on other things put me in a tough spot, because I have to maintain these apps for clients. So sembast feels a lot more future proof and reliable from that perspective.

Sembast documentation is not as good as HIVE (although hive has a lot of documentation issues despite the really nice navigation and layouts). But SEMBAST is professionally maintained and receives updates on a very regular basis. It has slightly different syntax and approach compared to hive. But there are more querying functions and abilities built in. Now that I've gotten used to it, and setup, I really like it.

Helpful Docs for anyone transitioning:

• Sembast nosql tutorial
• Freezed video tutorial, with json serialization instructions (https://youtu.be/ApvMmTrBaFI) (see comments for a minor annotation update)

With Hive, I was writing manual toJSON and fromJSON functions to map my data to online databases and export formats. So the fact that this is automated with freezed (or just json_serializable if you're not using freezed) actually makes my life easier.

[TheMisir]

Please help me by writing what's currently high priority issues. I'm planning to work to fix minor and major issues to make this package stable again.

Also, I'll publish the package with different temporary name (eg: hive-db or something like that) until @leisim gives us permission to publish packages to official hivedb pub.dev package.

[yringler]

@mdrideout , in regards to sembox - I understand that everything is loaded into memory? Which is not suitable for all projects. My data comes shipped in a nice sized chunk of JSON, so I prefer having hives lazyboxes (which only have to load the keys into memory)

With Hive, I was writing manual toJSON and fromJSON

You can automate this with json_serializable with hive, also.

[mdrideout]

@mdrideout , in regards to sembox - I understand that everything is loaded into memory? Which is not suitable for all projects. My data comes shipped in a nice sized chunk of JSON, so I prefer having hives lazyboxes (which only have to load the keys into memory)

I am sure there are situations where Hive's architecture could be beneficial. However, I have seen that people with even 10MB of storage in SEMBAST are still getting great performance, so I was hoping to offer an alternative for anyone facing the same dilemma. If you are storing a very large amount of data, I can't be sure sembast would work, but it would be interesting to test. In my case, my users probably won't even reach 1MB. Based on Hive's benchmarks graphs, you'd be led to believe everything else is painfully slow but I can't find evidence that anyone has performance issues with sembast.

The thing that really worries me about Hive is the lack of leadership, roadmap, and commitment to maintenance. It is just now after months of no response and issues building, that there is movement, and I really appreciate @TheMisir for taking on that role. But as of right now, it feels like a risk that is likely to inconvenience my clients, and increase my overhead and expenses with troubleshooting, delays, and refactoring in the future.

If leism had produced production apps for clients using hive, I am sure he'd have more skin in the game and would understand the issues the community is suddenly facing. But he has yet to allow anyone to update the pub.dev package still. So anyone using enums with hive_generator still is stuck after all this time (just one example).

[AKushWarrior]

That's... good for you? I understand the complaints about the maintainership situation, and I have my own gripes with @leisim, especially in his inactivity with regard to project management. On the other hand, it feels inappropriate to randomly hijack an issue about the future of a package to tell people about how another package is better.

[leisim]

I just added @TheMisir as uploader :+1:

If leism had produced production apps for clients using hive, I am sure he'd have more skin in the game and would understand the issues the community is suddenly facing.

I have 6 production apps using Hive ;)

[omidraha]

Exactly the same as me,
After this issue, I also migrated from Hive to Sqflite.

[leisim]

@omidraha C'mon this is not the place for such posts.

[AKushWarrior]

Btw @omidraha Hive 2.0. (Isar) will be platform independent and natively work on both Android and IOS.

[TheMisir]

I just updated packages. I hope this will solve dependency issues. Please let us know if something is not working again by opening an issue.

[tr-stan]

thank you @leisim for providing permissions to @TheMisir, and thank you TheMisir and others for your work! I know a few posts on this issue may have seemed a little much or off-topic, but I do want to emphasize they were relevant to the future of Hive, because: I am sure there are many others like myself on small startup teams, pretty new to the field and wanting to help maintain but not knowledgeable/confident enough to do so, and seeing months go by without any resolution to some pretty frustrating issues, it could lead a lot of people to drop Hive as an option and maybe even write it off for future consideration.

Even when there were others merging in PRs to fix numerous issues, those weren't available in the more widely/easily trusted medium of pub.dev because of a lack of either communication or who knows what. Too many potential users would have been hit with pretty high walls of entry into learning/using Hive, and for someone like myself it also discourages the idea of contributing once I even feel good enough, or smart enough. Of course in this field you need to be resourceful and learn each day how to surmount those walls, but I think having at least TheMisir, who is _currently_ capable of actively addressing _current_ issues and publishing to pub.dev is a great step to making the current state (and even more the future state) of Hive more accessible to everyone, regardless of their skill level.

Anyway, thanks again for all y'all have done! I see now that Hive 1.4.2 and other dependency updates have been pushed to pub.dev, and at least I ran them without any conflicts with my set of dependencies (including characters ^1.0.0), without having to reference the latest state of master branch in github directly in my pubspec.yaml. Such a happy moment!

Hopefully sometime in the future when I'm more experienced/confident and not fighting every day to get my first product into the world, I'll be able to contribute to Hive too. And I hope thanks to this step others will be encouraged to continue experimenting with and investing time into Hive. :)

[leisim]

@tr-stan Thanks for your opinion in this matter. To be clear, I don't want to censor any criticism. I agree that the lack of updates has not been optimal.

But I still think that this is not the right place to discuss how to replace Hive with something else. After all, this issue is called "The future of Hive" and not "The future without Hive" 😉

Edit: I'm also very happy and thankful that @TheMisir and others will continue development for now :+1:

Edit2: Don't hesitate to open a PR just because you think you don't have enough knowledge. Maybe you can start with small things like typos in docs etc.

[surajprasad]

@TheMisir @leisim looking for suggestions for my use case, I am looking at creating an asset tracking app where a user may have an average of 200 assets of different kinds. The box structure fits perfectly and the encryption provides for safety of the asset information too.

I am keen to know if I write an implementation with the latest stable version of hive (@TheMisir thanks for maintaining it) will the boxes be readable by Isar etc. in future. (What I mean is, whether objects written now can be accessible for read-only operations with future technologies).

Another noob question is whether data objects / boxes are transferable as it is to another device and be read on a new device given the same app and encryption keys, in other words are backups and restoration easy using hive. My use case does not need the boxes to be synced to a central database, they only need to reside in one place, signatures / pointers to the boxes are used in all other cases.

Thanks

[TheMisir]

I am keen to know if I write an implementation with the latest stable version of hive will the boxes be readable by Isar etc. in future.

I think this will be possible but a bit challenging. You have to read data from hive box and manually save to isar. Think like reading file from XML file and saving to JSON file. I would recommend adding some sort of storage abstraction layer between UI/logic and hive/isar. In that way you don't have to modify all the code when you change storage instead you will just modify code on that layer.

Another noob question is whether data objects / boxes are transferable as it is to another device and be read on a new device given the same app and encryption keys, in other words are backups and restoration easy using hive. My use case does not need the boxes to be synced to a central database, they only need to reside in one place, signatures / pointers to the boxes are used in all other cases.

You may transfer hive file and encryption key or I would suggest to manually export data to for example json file and read it when importing on other device. Because the data might corrupt (check Murphy's Law) if hive version mismatch between A and B devices. Also JSON is human readable format. The customer wont lost access to assets if data corrupts somehow.

[surajprasad]

I think this will be possible but a bit challenging. You have to read data from hive box and manually save to isar. Think like reading file from XML file and saving to JSON file. I would recommend adding some sort of storage abstraction layer between UI/logic and hive/isar. In that way you don't have to modify all the code when you change storage instead you will just modify code on that layer.

Is the current work on Isar taking into account the interoperability of objects created with the current hive db? I hope there are clear documentations to manage this transition for projects under development that use hive in the current status.

You may transfer hive file and encryption key or I would suggest to manually export data to for example json file and read it when importing on other device. Because the data might corrupt (check Murphy's Law) if hive version mismatch between A and B devices. Also JSON is human readable format. The customer wont lost access to assets if data corrupts somehow.

While JSON is excellent, I am still not very familiar with it and I am not too sure if I would use it since I want the data to remain encrypted, visible only to the authenticated users, if they choose to, otherwise a seamless transition to the new setup would be excellent.
I guess I am trying to make a decision to stay with Hive and port to Isar when convenient, mainly due to the simplicity of its implementation.
Great work!

[yringler]

I am still not very familiar with it and I am not too sure if I would use it since I want the data to remain encrypted, visible only to the authenticated users,

dart support for JSON is pretty good. You would want to create a class which could hold whatever data you currently have in hive.
If passing around unencrypted JSON is a concern... you could encrypt it. There are many encryption options available in dart.

[surajprasad]

dart support for JSON is pretty good. You would want to create a class which could hold whatever data you currently have in hive.
If passing around unencrypted JSON is a concern... you could encrypt it. There are many encryption options available in dart.

Thank you, thats helpful. Is there any clarity yet on the timeline for the release of a stable Isar candidate? thinking if I should redraw my timelines.

[leisim]

@surajprasad It will take a long time until Isar can be considered stable. Also, it will not replace Hive. There are still many use cases for Hive and we (currently mostly @TheMisir) will continue development.

[surajprasad]

@leisim Thank you so much for that, as for my use case, hive in its current form is good enough, and if it will continue to develop / be maintained, thats all I need to proceed with it, my concern was whether this will become obsolete and hence I would be forced to change to a different library.
Thank you, and wonderful work so far, may the force be with you!

[RaghavKaushal]

@leisim I'm planning to use hive in my flutter app, any idea when will hive 2 rollout?

[AKushWarrior]

@leisim I'm planning to use hive in my flutter app, any idea when will hive 2 rollout?

It's pretty far out; there's no hard estimate, but at least a few months for the full release.

[AndiDog]

What's the plan for web support? WebAssembly support isn't in all relevant browsers yet. Just started experimenting with hive v1 with Flutter to be cross-platform compatible.

[AKushWarrior]

What's the plan for web support? WebAssembly support isn't in all relevant browsers yet. Just started experimenting with hive v1 with Flutter to be cross-platform compatible.

It uses JS interop to wrap IndexedDB on web.

[dgandhi17]

@AKushWarrior few months meaning 2-3 months ? or rough estimate.

[leisim]

@dgandhi17 Hopefully we can publish a beta version in 2020. You can expect a stable version late Q1 2021.

[tanzilzubair]

thank you @leisim for providing permissions to @TheMisir, and thank you TheMisir and others for your work! I know a few posts on this issue may have seemed a little much or off-topic, but I do want to emphasize they were relevant to the future of Hive, because: I am sure there are many others like myself on small startup teams, pretty new to the field and wanting to help maintain but not knowledgeable/confident enough to do so, and seeing months go by without any resolution to some pretty frustrating issues, it could lead a lot of people to drop Hive as an option and maybe even write it off for future consideration.

Even when there were others merging in PRs to fix numerous issues, those weren't available in the more widely/easily trusted medium of pub.dev because of a lack of either communication or who knows what. Too many potential users would have been hit with pretty high walls of entry into learning/using Hive, and for someone like myself it also discourages the idea of contributing once I even feel good enough, or smart enough. Of course in this field you need to be resourceful and learn each day how to surmount those walls, but I think having at least TheMisir, who is _currently_ capable of actively addressing _current_ issues and publishing to pub.dev is a great step to making the current state (and even more the future state) of Hive more accessible to everyone, regardless of their skill level.

Anyway, thanks again for all y'all have done! I see now that Hive 1.4.2 and other dependency updates have been pushed to pub.dev, and at least I ran them without any conflicts with my set of dependencies (including characters ^1.0.0), without having to reference the latest state of master branch in github directly in my pubspec.yaml. Such a happy moment!

Hopefully sometime in the future when I'm more experienced/confident and not fighting every day to get my first product into the world, I'll be able to contribute to Hive too. And I hope thanks to this step others will be encouraged to continue experimenting with and investing time into Hive. :)

Taking from @tr-stan 's reply, I'm also a newbie, and I chose Hive because it was simple to understand , and coincidentally fit my use case as well.It helped me a lot, and I'd be only too happy to be able to give back to it, when I can find some free time.

I was thinking about starting with the already very good docs, maybe clearing some stuff up and making it even more newbie-friendly than it already is. I'm a beginner, and as such confused about how I should go about doing that.
Is that something I'm gonna need to do pull requests for, or is it on the docs website?.

Also, if there were simpler issues or features, I'd be glad to help as much as I could with them. Can't just let @TheMisir carry the entire thing on his back, ya know?

EDIT: I'm good with planning and stuff too, so I could be of help in issue tracking and prioritizing the major and problematic ones.Anyway I can help, I'll try my best.

[misterfourtytwo]

[leisim]

@Tanzil7274 Help in every shape or form is definitely greatly appreciated. @TheMisir does an amazing job maintaining Hive singlehandedly but I'm sure he doesn't mind a little help ;)

If you want to improve the docs (which is definitely a good idea especially to make Hive easier for beginners), just create a PR in the docs repo. You'll instantly see a test deployment and once the PR is merged, the website will be updated automatically.

If you have further questions regarding organization or contribution, just ask :+1:

[Hamza-Shewa]

hi everyone I've just started using Hive DB with a flutter web app, I've created a POS system and I realized after completing the whole development process that hive stores data in the browser Indexed DB, now I'm afraid of something happening and deleting the whole DB, and this is a problem since you can't create a backup from your DB!
any solution for this or should I just dump the system and start over again

[TheMisir]

hi everyone I've just started using Hive DB with a flutter web app, I've created a POS system and I realized after completing the whole development process that hive stores data in the browser Indexed DB, now I'm afraid of something happening and deleting the whole DB, and this is a problem since you can't create a backup from your DB!
any solution for this or should I just dump the system and start over again

You could use Box.toMap() and export all data into map then convert it to json (maybe using json_serializable) to save it. Or you can use javascript to export data from indexed db which I think it would be much easier to do.

https://stackoverflow.com/questions/17783719/import-and-export-indexeddb-data

[Hamza-Shewa]

hi everyone I've just started using Hive DB with a flutter web app, I've created a POS system and I realized after completing the whole development process that hive stores data in the browser Indexed DB, now I'm afraid of something happening and deleting the whole DB, and this is a problem since you can't create a backup from your DB!
any solution for this or should I just dump the system and start over again

You could use Box.toMap() and export all data into map then convert it to json (maybe using json_serializable) to save it. Or you can use javascript to export data from indexed db which I think it would be much easier to do.

https://stackoverflow.com/questions/17783719/import-and-export-indexeddb-data

you're a real hero bro

[pdmshrestha]

What about geospatial? Will it be supported in new version?

[TheMisir]

What about geospatial? Will it be supported in new version?

What do you mean by geospatial? You can always write custom data adapters for supporting anything that doesn't supported internally by hive. (Hive also uses adapters for supporting complex data types).

[pdmshrestha]

What about geospatial? Will it be supported in new version?

What do you mean by geospatial? You can always write custom data adapters for supporting anything that doesn't supported internally by hive. (Hive also uses adapters for supporting complex data types).

I mean to say GeoPoint queries.

[TheMisir]

I mean which dart file (package, file, etc) declares GeoPoint class?

[mbaumgartenbr]

Hey guys! Any plans on migrating to null-safety? Cheers!

[TheMisir]

Hey guys! Any plans on migrating to null-safety? Cheers!

I don't have any idea how to safely migrate to null-safety without breaking null-safety disabled users.

[ryanheise]

You can create a prerelease with a minimum SDK constraint of Dart 2.12: https://medium.com/dartlang/announcing-dart-null-safety-beta-87610fee6730

[TheMisir]

You can create a prerelease with a minimum SDK constraint of Dart 2.12: https://medium.com/dartlang/announcing-dart-null-safety-beta-87610fee6730

Thank you so much! We'll track null-safety implementation in #496 .

[Hassico]

I am not really a pro with what's happening in this conversation but I would like to suggest something. My app relies heavily on Hive, it is awesome, but one annoying thing is that when I perform a background task and alter a box, changes cannot be enforced into the app unless I close and reopen the box. Communicating between isolates is a hindrance especially with workmanager. So any workaround to allow alteration of boxes from different isolates would be great and appreciated. Thank you.

[leisim]

@Hassico I had a completely working prototype with Hive running in multiple isolates. Unfortunately I had to kill it because the performance was much worse than running it in a single isolate.
The synchronization is really expensive because of the unfortunate choices the Dart team made when developing isolates. Especially the missing shared memory is a problem.

TLDR: Not going to happen any time soon unless someone has an idea how to make it fast :/

[listepo]

@dgandhi17 Hopefully we can publish a beta version in 2020. You can expect a stable version late Q1 2021.

@leisim any news?

[leisim]

@listepo Yes, Isar is very close to being ready. I plan to publish an alpha version today or tomorrow.

[listepo]

@leisim thanks, that's good news

[escamoteur]

Hi, I'm just stumbeld upon this and am a bit surprised about your plans.

1. Why do you think Dart objects are so much bigger than Rust ones that you wil get a big improvement
2. Sure Rust is fast, but have you meassured how much faster than a release compile in Dart?
   maybe @leafpetersen can say something to that.
3. When using a Rust library with ffi you add a second standard library to your app which might make all memory gains void.
4. Realm will soon be available for Flutter according to one of the devs
5. ObjectBox is another really fast existing alternative.

I also think you can't make a breaking change that will break installed apps after an update.
If you really think its a good idea, start a new package with the new API and data format. Otherwise you have at least to include a converter in the new version
Not to demotivate you, I'm just not sure if this is the right way to spend your energy
Thomas

[AKushWarrior]

Hi, I'm just stumbeld upon this and am a bit surprised about your plans.

1. Why do you think Dart objects are so much bigger than Rust ones that you wil get a big improvement
2. Sure Rust is fast, but have you meassured how much faster than a release compile in Dart?
   maybe @leafpetersen can say something to that.
3. When using a Rust library with ffi you add a second standard library to your app which might make all memory gains void.
4. Realm will soon be available for Flutter according to one of the devs
5. ObjectBox is another really fast existing alternative.

I also think you can't make a breaking change that will break installed apps after an update.
If you really think its a good idea, start a new package with the new API and data format. Otherwise you have at least to include a converter in the new version
Not to demotivate you, I'm just not sure if this is the right way to spend your energy
Thomas

I'm not sure if you've read the entirety of this issue. After some deliberation, Simon decided to create a new package named Isar to house this Hive 2.0, and leave Hive as is.

As to speed gains: Rust (and C++, and C) is much, much faster than Dart. That's the whole point of dart:ffi: to leverage the speed of established native libraries in Dart applications.

The raw speed at which LMDB operates isn't even approached by anything that you can produce in Dart, not to mention the pitfalls in reproducing work that has been carefully performed by others in the past.

[escamoteur]

@AKushWarrior thanks for pointing out, indeed after the half of the thread I skipped a large part.
I know that ffi is to leverage exisiting libraries.
I still would like to see actual benchmarks of a dart native compiled piece of pure algorithm to one on rust to know how big the difference is.
Even more so to know how big the difference in memory per object is.

Ah, I just realized that he want's to wrapp the existing database LMDB. And sure if you heavily use pointers you will be faster than normal Dart in many situations.
But does LMDB support the targeted complex queries?

[leisim]

@escamoteur

1. That is not the reason why we need a new database. The problem ist that it is very expensive to keep all the entries of a database in memory. Unfortunately Dart is very slow when it comes to File IO and has no support for mmap or something similar. Another very big issue is multi Isolate support. Since there is no shared memory and no fast way of synchronization, it is very expensive to keep Hive in sync across isolates.
2. Yes. I did a lot of measurements and Dart is not even comparable to Rust. That is not surprising and nothing against Dart, the languages are just very different. To be clear: Isar is magnitudes faster than Hive. FFI reduces this advantage a bit but it's still impressive ;)
3. I didn't know of memory overhead of the FFI interface? Could you elaborate this point?
4. 
   
   
   
   1. If that's the case, even better for Flutter users. I don't see the problem here. After all, the goal of Isar is to make a database that works on all devices (including web) with the same API. This is something neither Realm nor Objectbox will ever achieve (IndexedDB limitations)
   
   

Hive and Isar are so different that it is a good idea to keep both around. I learned a lot while writing Hive and I hope to have finally created the perfect database for flutter. Isar will support the following.

• Compile time checked and autocompleted queries
• True asynchronous execution
• Indexes and compound indexes
• Zero configuration
• Query subscription (executed asynchronous)
• Multi Isolate support
• Automatic schema migration (without any config files)
• Soon: Support on Web
• Not so soon: Open source and free for everyone sync

[escamoteur]

Hi @leisim,

sorry when writing my post I hadn't realized that you have started with ISAR which is based on an established Database which I find a really good idea.

on 3. The thing is that every language adds its standrard library to the memory footprint of the App. So you will have two standard libs with similar functionality (Dart & Rust) in your App. But in the case of Isar that makes perfect sense.
Looking forward to see how it goes. I highly recommend getting some partner on board to do code reviews and discuss concepts. Distributing a databas is a takes a lot of responsibilty.

[leisim]

@escamoteur Oh you are talking about the binary size of the app. Yes that is true. Isar will slightly increase the APK size but I hope it won't be too big of an issue.

Yes I agree. A lot of people will need to read and validate the code before we can stabilize the database. Isar Core is almost feature complete and I invite everyone who is interested to take a look. If you need help with something, just ping me and I'll be happy to help. I'll make sure to also document the core code well but I need some time for that.

There is also a company that is interested in Isar and I hope to receive some feedback from them.

[leisim]

I just released the first version of Isar. There is no documentation yet and it is far from stable...

[dgandhi17]

I just released the first version of Isar. There is no documentation yet and it is far from stable...

I still see "Very unstable and not ready for serious usage". Are you sure this is stable as I am planning to use it in my app.

[AKushWarrior]

@dgandhi17 "far from stable" is an idiom meaning that it's currently very unstable. It is NOT stable and probably shouldn't be used in production.

[dgandhi17]

@dgandhi17 "far from stable" is an idiom meaning that it's currently very unstable. It is NOT stable and probably shouldn't be used in production.

I understood the opposite never mind

[leisim]

@dgandhi17 You should definitely not use it in a production app currently 😱

[bradyt]

Would such a Rust implementation be compatible with F-Droid's policies? I don't fully understand the issues, but I hope such a Rust implementation would not create issues like this one:

The progress on this issue has stalled because F-Droid does not allow AAR libraries anymore. To work around this we need to compile all required NativeScript plugins and then use them to build the app.

From https://github.com/xuhcc/beancount-mobile/issues/1#issuecomment-756312735.

[AKushWarrior]

This should really be filed over on the Isar repository (because this repository does not and will not house a Rust implementation), but I would guess that Isar apps will end up running into that issue as well.

The idea behind FFI in Flutter is that Flutter can load native (C or C++) libraries through Android and IOS capabilities. Since Rust can compile to the relevant targets (LLVM), we can use FFI in Flutter to run Rust functions. In Android, these native libraries are distributed as AAR.

If F-Droid doesn't support AAR dependencies (and instead supports some other compilation target for native dependencies), then you'd have to compile the Rust code to that target, and then find a way to statically link to it. Depending on what API F-Droid exposes (and its parity to the normal Android one) that could either be relatively easy or pretty hard.

[yringler]

Wow I must have been living under a rock for the last few months (or just been busy). Isar is alive! Wow! @leisim, looks incredible!
I can't wait to switch to it from hive. Hive is great, but I feel like my massive data size (even with lazy box) is a ticking time bomb.
I have an app with 600+ users, can't wait for Isar to be stable enough to switch!

[leisim]

@yringler Yes I'm quite happy with the progress. According to my tests and benchmarks, Isar will probably solve all problems people have with Hive currently.

[dgandhi17]

@leisim Can we expect stable version by this month?

[leisim]

@dgandhi17 stable probably not because that implies that it has been battle tested. You can expect a beta version within the next few weeks.

[michalisioak]

A noob opinion:
may sound silly but what if we make hivedb a system service and though IPC (interprocess communication) talk to dart clients (and may other languages)

Advantages ( I thought)

1. less storage taken
2. later support for having the same database stored on all user devices
3. modularization

Disadvantages ( I also thought)

1. more complicated (client must be different from the service)
2. dont know how to implement this
3. security, (in my head, every application would have a key initialized hardcoded in the app, something like containerization but for db)

Feel free to correct me and point if this is possible

[ryanheise]

Apart from queries, Hive has another problem: Dart objects use much RAM. Since Hive currently keeps at least the keys in RAM, you can hit the OS limit of mobile devices quite fast.

Casual observer here, but I wonder whether Dart compiler improvements are having/will have any impact.

The new compiler in SDK 2.12 contains memory and performance optimisations when code is compiled with sound null safety.

Some other enhancements on the roadmap:

https://github.com/dart-lang/sdk/projects/23#card-55259467

[Hassico]

Humble Hive user here. Is it possible to make data posts or hive files have max age, stale ... options like we find in caching properties?

[erf]

I only need a db solution for my dart server project, have you thought about making a pure dart wrapper around LMDB as a side project to avoid bloat by including indexdb etc.

I'm using Redis now, but i suspect LMDB would be faster.

[erf]

Maybe some benchmarks for isar would be interesting. Comparing with some other popular db solutions, including Hive, Redis, sembast, sqflite etc.

[leisim]

@erf Dart is very good at tree shaking unused code so the indexeddb wrapper will never be included in your mobile app build.

Redis is an in-memory database so it's likely faster than anything else. I'm not sure benchmarks are very useful here because the databases are completely different. That being said I expect Isar to be faster than all other databases currently available for Flutter.

Currently I have more important tasks (unit tests 🙄) than writing a benchmark but maybe someone from the community will write one.

[wesleytoshio]

Hello, is it already possible to use custom queries? or sort by date as you said at the beginning of the post?