# Adding jsonb columns for custom fields

**URL:** https://meta.discourse.org/t/adding-jsonb-columns-for-custom-fields/93418
**Category:** Development
**Created:** [July 29, 2018, 6:55pm UTC](https://meta.discourse.org/t/adding-jsonb-columns-for-custom-fields/93418 "2018-07-29T18:55:48Z")
**Posts on this page:** 1
**Showing post:** 13

<div class="post-metadata">

### Author: ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)
#### Post date: [August 15, 2018, 11:51pm UTC](https://meta.discourse.org/t/adding-jsonb-columns-for-custom-fields/93418/13 "2018-08-15T23:51:38Z")

</div>

> [@j.jaffeux](#):
>
> Maybe we should provide some guidelines on when we think pluginstore is appropriate and when we think it’s not and people should use migrations.

The general guidelines for using plugin store would be for

- Tiny amounts of data
- You do not think you will need to query it

Overall, actual use cases for PluginStore should be very very small. For example even our existing cases where we use it are misuses imo cause tidy tables here would help a lot.

- staff notes should be a table
- [data explorer](https://meta.discourse.org/t/32566?silent=true) is really messy in the way it uses it and should use a table
- oauth2 basic belongs in the new tables @david is suggesting
- canned replies should be in a table

Regarding the “but I really really want to remove all traces of a plugin, problem”

Firstly, we are not cleaning up plugin store properly anyway. Secondly, if you make the migrations reversible we can just run them in reverse. The big risk around “adding extra tables” is that 2 plugins may fight for 1, which is why I suggested a central registry in core.

---

_[View the full topic](https://meta.discourse.org/t/adding-jsonb-columns-for-custom-fields/93418)._