ODD Platform for Open Data Discovery and Observability

What ODD Platform centralizes for data teams

ODD Platform addresses the problem of finding data, understanding where it came from, and determining whether its quality or availability has changed. Its intended users are data practitioners, including data engineers, scientists, analysts, and teams responsible for governance. The repository presents ODD as a reference implementation of the Open Data Discovery Spec, which makes the platform relevant when an organization wants catalog metadata to follow a shared model rather than remain inside separate tools.

The catalog is federated rather than presented as a replacement for every underlying system. ODD collects information from sources such as Airflow, Apache Druid, Cassandra, Clickhouse, Elasticsearch, databases, and other integrations, then places their metadata into a common catalog. The README also lists support for Great Expectations, DBT tests, custom data-quality frameworks, and reference or lookup tables. This makes the project more than a searchable asset index. It provides a place to relate data objects, inspect pipeline movement, record quality signals, attach tags, and store metadata.

ODD is not positioned as a general business intelligence tool. It is infrastructure between data producers and the people who consume their outputs. The distinction matters because the platform cannot make a dashboard self-explanatory unless the relevant lineage and metadata have reached ODD. Its value therefore depends on connector coverage and on how completely teams publish operational context.

How the catalog models discovery, lineage, and quality

The repository is organized as a multi-module Java project. The top level includes `odd-platform-api`, `odd-platform-api-contract`, `odd-platform-specification`, `injector`, and `odd-platform-ui`, alongside build and test infrastructure. Based on this layout, the platform separates its backend API, API definitions, specification-related code, UI, and injectable integration behavior. The README also points to a separate container named `odd-platform-enricher` for the Docker Compose path, indicating that metadata enrichment is deployed as a distinct process rather than being limited to the web application.

The documented information flow starts with external collectors or adapters. Integrations include Airflow adapters and collector-based connectors for systems such as Druid, Cassandra, Clickhouse, and Elasticsearch. Adapter or collector output enters the ODD environment, where the platform can retain metadata and relate data objects through end-to-end data and microservice lineage. Pipeline monitoring is intended to produce warnings and alerts, while the quality dashboard presents metrics, trends, and issues across datasets.

This design separates discovery from the systems that execute data work. ODD does not need to replace Airflow or the database itself. Its role is to collect and organize the evidence those systems produce. The visible trade-off is that this architecture depends on synchronization and connector behavior. The README does not document refresh timing, retry policy, deletion semantics, or rollback, so operators should not infer those operational details from the feature list.

Running ODD Platform with PostgreSQL and Docker

The simplest documented starting path launches the platform container against an existing PostgreSQL database. The following configuration defines the connection details used by the next command. Replace the example credentials for a real environment and make sure PostgreSQL accepts connections from the Docker container.

export POSTGRES_HOST=172.17.0.1
export POSTGRES_PORT=5432
export POSTGRES_DATABASE=postgres
export POSTGRES_USER=postgres
export POSTGRES_PASSWORD=mysecretpassword

This example uses a host address that may need to match the local Docker networking arrangement. The README does not provide a readiness check, login procedure, or first catalog ingestion command, so success at this stage is only the container being started and the web endpoint becoming reachable.

Start the published platform image with the configured PostgreSQL connection. Port `8080` is mapped from the container to the host.

docker run -d \
  --name odd-platform \
  -e SPRING_DATASOURCE_URL=jdbc:postgresql://${POSTGRES_HOST}:${POSTGRES_PORT}/${POSTGRES_DATABASE} \
  -e SPRING_DATASOURCE_USERNAME=${POSTGRES_USER} \
  -e SPRING_DATASOURCE_PASSWORD=${POSTGRES_PASSWORD} \
  -p 8080:8080 \
  ghcr.io/opendatadiscovery/odd-platform:latest

The command creates a detached container named `odd-platform`. For a local environment, open `http://localhost:8080`. The README does not state whether authentication is required or how an initial account is created, so those details must be established from the project documentation or deployment configuration.

For a Compose-based setup, the repository uses a separate deployment file and starts the enricher service:

docker-compose -f docker/demo.yaml up -d odd-platform-enricher

That command starts only the named enricher service from the demo configuration. It should not be treated as a complete production deployment because the README does not list the other services, their dependencies, or persistent storage settings in this section.

Connector coverage as the main adoption constraint

ODD Platform's feature set only matters when the underlying systems publish useful metadata. The README lists integrations with Airflow, Airflow 2+, Apache Druid, Cassandra, Clickhouse, and Elasticsearch, with several implemented through `odd-collectors`. It also states compatibility with Great Expectations and DBT tests and says that custom data-quality frameworks can be integrated.

This connector model is preferable to a catalog populated by hand when an organization has established integration paths. It can place pipeline and source metadata into one model instead of asking users to search each operational tool. However, the feature descriptions do not provide connector version matrices, supported metadata fields, authentication instructions, or upgrade compatibility. They also do not establish whether every listed integration is complete, experimental, maintained at the same rate, or limited to a particular object type.

The absence of complete integration documentation in the README is a concrete adoption risk. A team using a warehouse, orchestration engine, transformation layer, or quality library should first determine which exact systems must be connected. If none is listed, custom adapter work may be required. If several are listed, the team still needs to verify the object model, credential handling, update behavior, and deletion behavior before making ODD the authoritative catalog.

ODD is therefore a poor fit for an organization seeking a zero-configuration catalog that automatically understands every proprietary system. Its fit improves when common tools already have adapters and the organization accepts responsibility for operating the connectors and keeping their metadata complete.

Apache-2.0 licensing and maintenance boundaries

ODD Platform uses the Apache-2.0 license. That permits use and modification under the license's stated conditions, but this review does not interpret obligations for a particular deployment. Teams should examine `LICENSE.md` for required notices and attribution, and review `SECURITY.md` before placing sensitive catalog metadata in the service.

The repository is not archived, and its last push was on 2026-09-22. The recent release history includes version `0.29.0` on 2026-06-26, `0.28.0` on 2026-06-17, and `0.27.13` on 2026-04-03. These records support a current maintenance picture, but the version numbers below `1.0.0` also mean that interface and compatibility changes remain a plausible upgrade concern.

Using the `:latest` tag in the documented `docker run` command simplifies the first launch, though it does not pin a reproducible application version. Production operators need to determine how releases affect database migrations, API contracts, adapters, UI behavior, and environment variables. The README excerpt does not document an upgrade procedure or rollback path, so those points require confirmation before replacing an existing instance.

The deployment also creates operating cost beyond the Java application. PostgreSQL must be backed up and secured, and every enabled connector must have credentials, monitoring, and a recovery plan. A catalog can contain descriptions and lineage that reveal sensitive business relationships, making access control and data handling requirements part of adoption rather than optional follow-up work.

ODD Platform versus source-local exploration

A source-local approach is a genuine alternative for teams that work primarily inside one warehouse, orchestration interface, or notebook environment. Such teams may use the native catalog, query history, pipeline UI, and data-quality screens already provided by those systems. This avoids operating another catalog and another set of connectors, but it leaves discovery fragmented when data moves among several services.

ODD takes the opposite approach. It receives metadata through collectors and adapters, stores the catalog centrally, and relates objects across systems. That is useful when a dashboard depends on several upstream datasets, when analysts need one search point, or when governance and data teams must review lineage beyond a single tool. The cost is infrastructure, integration ownership, and a synchronization layer whose failure behavior is not described in the README.

A smaller data team with one dominant source may get less value from that arrangement. A multi-system data organization has a clearer use case, provided its required connectors exist. The practical comparison is therefore not feature count. It is whether centralized discovery and cross-system relationships solve a problem that the current source-local tools cannot cover.

Editorial conclusion

Data teams operating several warehouses, pipelines, and transformation tools should evaluate ODD Platform when centralized discovery, lineage, and quality visibility outweigh the cost of maintaining its integrations and PostgreSQL deployment. Smaller teams with one well-documented data stack should verify integration coverage first. A practical first check is whether the relevant Airflow, database, quality, or custom integration exists and can populate the catalog in the deployment environment.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. opendatadiscovery/odd-platform on GitHub
3. Project website
4. README
5. Releases