Here is way to corrupt your db:

Take 2 pendrives A and B
Plug them in in this order: A > B

Assuming they are mounted inside /run/media/otto/

$ find /run/media/otto/5714-D674 -exec balooctl index {} \;

(files are indexed)

$ find /run/media/otto/5714-D674 -exec balooshow {} \;

(index information is printed)

$ stat -c "%D %n" /run/media/otto/*
831 /run/media/otto/5714-D674
820 /run/media/otto/CDFD-AE5C

Unmount and unplug the drives
Plug them in again in this order: B > A

$ stat -c "%D %n" /run/media/otto/*
821 /run/media/otto/5714-D674
830 /run/media/otto/CDFD-AE5C

Drive A now has a different device id. As consequence:

$ find /run/media/otto/5714-D674 -exec balooshow {} \;
No index information found
No index information found
No index information found
No index information found
No index information found
No index information found
...

For removable drives (or, more specifically, anything outside the users home directory):

• store in a separate database
• store the database either
  • toplevel on the filesystem, as a hidden directory -or-
  • as a separate database in the usual baloo db location, i.e. ~/.local/share/baloo

The or should be user configurable (with default and per drive), and could be integrated with e.g. the automounter (which already has to identify external drives uniquely)

For network shares:
Samba allows remote searching using a server-side index. "Just" integrate with that.

I experience the same behavior with BTRFS subvolumes mounted by systemd mount units.
Not on every boot, but after a seemingly random number of boots the device id changed and Baloo indexes the subvolume all over again.