DipDup supports several database engines for development and production. The obligatory field kind specifies which engine has to be used:

  • sqlite
  • postgres (and compatible engines)

6.1. Database engines article may help you choose a database that better suits your needs.


path field must be either path to the .sqlite3 file or :memory: to keep a database in memory only (default):

  kind: sqlite
  path: db.sqlite3
kindalways 'sqlite'
pathPath to .sqlite3 file, leave default for in-memory database


Requires host, port, user, password, and database fields. You can set schema_name to values other than public, but Hasura integration won't be available.

  kind: postgres
  host: db
  port: 5432
  user: dipdup
  password: ${POSTGRES_PASSWORD:-changeme}
  database: dipdup
  schema_name: public
kindalways 'postgres'
databaseDatabase name
schema_nameSchema name
immune_tablesList of tables to preserve during reindexing
connection_timeoutConnection timeout in seconds

You can also use compose-style environment variable substitutions with default values for secrets and other fields. See 2.7. Templates and variables.

Immune tables

You might want to keep several tables during schema wipe if the data in them is not dependent on index states yet heavy. A typical example is indexing IPFS data — changes in your code won't affect off-chain storage, so you can safely reuse this data.

    - ipfs_assets

immune_tables is an optional array of table names that will be ignored during schema wipe. Once an immune table is created, DipDup will never touch it again; to change the schema of an immune table, you need to perform a migration manually. Check schema export output before doing this to ensure the resulting schema is the same as Tortoise ORM would generate.