Database configuration for Schema Registry

Schema Registry requires a storage backend to persist schema metadata, versions, and compatibility settings. You can choose between PostgreSQL for production deployments or an in-memory database for testing and development environments.

Configuring a PostgreSQL database for Schema Registry

Configure persistent database storage for production Schema Registry deployments using PostgreSQL.

PostgreSQL is the recommended database backend for production deployments of Schema Registry. It provides persistent storage, high availability, and scalability for schema metadata. Configuration is done using database properties. You must specify the database type, JDBC connection URL, username, as well as a database password. You also specify a TLS Secret to mount certificate files for encrypted connections.

  • You have access to a PostgreSQL server with TLS and have provisioned a database for Schema Registry.

  • Get the JDBC URL for the PostgreSQL server. Referred to as [***POSTGRESQL JDBC URL***] in the following steps.

  • Get a username that Schema Registry can use to connect to the PostgreSQL server. Referred to as [***POSTGRESQL USERNAME***].
  1. Prepare Secrets for required PostgreSQL connection values.
    Typically, you will need a Secret containing the PostgreSQL database password. Depending on your security requirements, an additional Secret might be required to hold TLS-related files, such as a Certificate Authority (CA) certificate used to establish a secure database connection.
    1. Create a Secret containing the PostgreSQL server password
      kubectl create secret generic [***POSTGRESQL PASSWORD SECRET NAME***] \
        --namespace [***NAMESPACE***] \
        --from-file=[***POSTGRESQL PASSWORD SECRET KEY***]=[***PATH TO DATABASE PASSWORD FILE***]
    2. Create a Secret containing TLS configuration files.
      All files included in this Secret will be mounted to a common directory in the Pod, allowing the files to be referenced in your JDBC URL. In this example, a single CA certificate is added.
      kubectl create secret generic [***POSTGRESQL TLS SECRET NAME***] \
        --namespace [***NAMESPACE***] \ 
        --from-file=[***PATH TO CA CERTIFICATE***]
  2. Configure database properties in a values file (values.yaml).
    #....
    database:
      type: postgresql
      jdbcUrl: [***POSTGRESQL JDBC URL***]
      username: [***POSTGRESQL USERNAME***]
      password:
        secretKeyRef:
          name: [***POSTGRESQL PASSWORD SECRET NAME***]
          key: [***POSTGRESQL PASSWORD SECRET KEY***]
      tls:
        secretRef: [***POSTGRESQL TLS SECRET NAME***]
    • database.jdbcUrl – The JDBC URL that points to your PostgreSQL database.

    • database.username – The PostgreSQL username for Schema Registry database connections.

    • database.password.secretKeyRef.name – The name of the Secret containing the PostgreSQL database password.

    • database.password.secretKeyRef.key – The key in the Secret specified by database.password.secretKeyRef.name that contains the PostgreSQL database password.

    • database.tls.secretRef – The name of a Secret containing TLS configuration for PostgreSQL connections (certificates, truststores, and so on). All keys from the Secret are mounted to /etc/schema-registry/postgres/tls. Reference mounted files in your JDBC URL (database.jdbcUrl) to configure SSL connections if SSL is required for PostgreSQL.

  3. Apply configuration changes.
    helm upgrade schema-registry [***CHART***] \
      --namespace [***NAMESPACE***] \
      --values values.yaml \
      --reuse-values
The PostgreSQL database is configured. Schema Registry now uses the specified database to persistently store schemas.

PostgreSQL TLS configuration

Reference a Kubernetes Secret containing certificate files to enable and configure TLS encryption for PostgreSQL connections.

The database.tls.secretRef property specifies a Secret containing certificate files for TLS connections to PostgreSQL. When configured, all keys from the Secret are mounted to /etc/schema-registry/postgres/tls inside the Schema Registry Pods. You then reference mounted files in your JDBC URL (database.jdbcUrl) to enable TLS.

The Secret you specify in the database.tls.secretRef property can contain various types of TLS-related files that are needed to establish an encrypted connection. The exact files the Secret must contain depends on the security requirements of your PostgreSQL server. Typically the Secret must contain a Certificate Authority (CA) certificate, which is used to verify the PostgreSQL server's identity.

Once mounted, files are referenced in your JDBC URL to enable TLS. For example, if your Secret contains a CA certificate file named ca.crt, your JDBC URL will be similar to the following example:
jdbc:postgresql://my-postgres-host:5432/schema_registry?sslmode=verify-full&sslrootcert=/etc/schema-registry/postgres/tls/ca.crt
Notice how the sslrootcert parameter points to /etc/schema-registry/postgres/tls/ca.crt. This ensures the JDBC driver can find the certificate provided by your Secret at its designated mount point within the filesystem of the Pod.

Configuring an in-memory database for Schema Registry

Configure and ephemeral in-memory database for development and testing environments.

The in-memory database is designed for testing, development, and demonstration purposes. It stores all schema metadata in memory, which means data is lost when Schema Registry Pods restart. Configuration is done by setting the database.type property to in-memory.

  1. Configure an in-memory database in your values.yaml.
    #...
    database:
      type: in-memory
  2. Apply configuration changes.
    helm upgrade schema-registry [***CHART***] \
      --namespace [***NAMESPACE***] \
      --values values.yaml \
      --reuse-values

Schema Registry is configured to use an in-memory database for schema storage.