# Dgraph schema alteration good practices

**URL:** <https://discuss.dgraph.io/t/dgraph-schema-alteration-good-practices/6220>\
**Category:** Dgraph\
**Created:** [March 31, 2020, 1:52pm UTC](https://discuss.dgraph.io/t/dgraph-schema-alteration-good-practices/6220 "2020-03-31T13:52:57Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sceat](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/sceat/32/2612_2.png) [@Sceat](https://discuss.dgraph.io/u/Sceat)\
**Post date:** [March 31, 2020, 1:52pm UTC](https://discuss.dgraph.io/t/dgraph-schema-alteration-good-practices/6220/1 "2020-03-31T13:52:57Z")

</div>

Hi, i would like to **discuss** about how a Schema should be managed.

> related to [#3645](http://discuss.hypermode.com/t/alter-the-same-schema-server-times/3645)

In a container environment where the app is replicated and often start/shutdown concurrently it would not be wise to alter the schema on start as Dgraph doesn’t seem to check for existing predicates and just override, is there some practices/solutions for this ?

The first thing coming to my mind would be to setup a repository dedicated only to manage the entire Dgraph schema for my product/app thus becoming available to a CI/CD controlled environment. I’d like some community advice on this subject, how do you manage you schemas ? how would you do it ? what are the alternatives ?

Thanks.

---

<div class="post-metadata">

**Author:** ![wildan2711](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/wildan2711/32/1320_2.png) [@wildan2711](https://discuss.dgraph.io/u/wildan2711)\
**Post date:** [April 1, 2020, 2:24am UTC](https://discuss.dgraph.io/t/dgraph-schema-alteration-good-practices/6220/2 "2020-04-01T02:24:56Z")

</div>

Hi @Sceat, what language is your Dgraph client?

If you’re using the Go Dgraph client, a suggestion is that you can use [Dgman](https://github.com/dolan-in/dgman) to manage your schemas. It has a `CreateSchema` function that will create and detect existing or duplicate predicates in your schema, preventing overwrites and reindexing your predicates.

---

<div class="post-metadata">

**Author:** ![Sceat](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/sceat/32/2612_2.png) [@Sceat](https://discuss.dgraph.io/u/Sceat)\
**Post date:** [April 1, 2020, 8:02am UTC](https://discuss.dgraph.io/t/dgraph-schema-alteration-good-practices/6220/3 "2020-04-01T08:02:32Z")

</div>

Hi, i’m using the javascript client, if we can actually pull the whole schema from Dgrpah, detecting conflict is indeed a good solution

---

<div class="post-metadata">

**Author:** ![prashant-shahi](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/prashant-shahi/32/1921_2.png) [@prashant-shahi](https://discuss.dgraph.io/u/prashant-shahi)\
**Post date:** [June 2, 2020, 9:37pm UTC](https://discuss.dgraph.io/t/dgraph-schema-alteration-good-practices/6220/4 "2020-06-02T21:37:22Z")

</div>

Hi @Sceat, starting from [Dgraph v20.03.0](https://github.com/dgraph-io/dgraph/releases/tag/v20.03.0), background indexing has been introduced. It only updates the predicates and its indexes if it is different from the existing Dgraph schema while mutations and queries continue to work.

Here an example from JS client:

```auto
const schema = "name: string @index(exact) .";
const op = new dgraph.Operation();
op.setSchema(schema);
op.setRunInBackground(true);
await dgraphClient.alter(op);

```