Database indexes in Django 1.11: difference between db_true, indexes and index_together

Question

Django 1.11 offers new ways to create database indexes. So far we had db_index=True in each field:

# example 1

class Person(models.Model):
    name = models.CharField(db_index=True)
    age = models.IntegerField(db_index=True)

Now we have models.Index and the possibility of declaring indexes within the class Meta block — or even index_together.

That said I have two doubts:

1. Is the code from example 1 doing the same thing as example 2 below?

# example 2

class Person(models.Model):
    name = models.CharField()
    age = models.IntegerField()

    class Meta:
        indexes = [
            models.Index(fields=['name']),
            models.Index(fields=['age'])
        ]

2. What about index with multiple fields and index_together: are examples 3 and 4 below doing exactly the same thing?

# example 3

class Person(models.Model):
    name = models.CharField()
    age = models.IntegerField()

    class Meta:
        indexes = [
            models.Index(fields=['name', 'age'])
        ]

# example 4

class Person(models.Model):
    name = models.CharField()
    age = models.IntegerField()

    class Meta:
        index_together = [['name', 'age']]

What are the diferences between 1 and 2, and differences between 3 and 4? What am I missing? Many thanks.

Answer 1

According to the docs, you can give indexes a name and you can set an order for each field in the index (but not all DBs are equally supported). But in reality the whole point of this is to bring extra flexibility to define other types of indexes where supported.

Currently as of Django 1.11 and only when using Postgres you can define GIN and BRIN indexes if that is something that would fit your needs. (see django.contrib.postgres.indexes at https://docs.djangoproject.com/en/1.11/ref/contrib/postgres/indexes/)

Being able to define indexes as you described is just the most general case and unless you want to use a feature named above (naming indexes or ordering fields) you can probably use indexes as you've been doing until now (db_index and index_together).