Change Log

Available to: Everyone

Notable changes to TitanRDM, newest first. Version numbers follow semantic versioning: a new major version contains changes that may require you to update API integrations.

2.1.0 — October 2026

CI/CD Integration and Service Accounts

Your CI/CD pipeline can now promote and deploy reference data alongside your data platform code, addressing TitanRDM by pull request and release stage. See CI/CD Integration.

New

  • CI/CD endpoints:
    • POST /api/v1/cicd/promote promotes the promotion for a merged pull request.
    • POST /api/v1/cicd/deploy deploys a release to an environment: everything promoted up to the release, oldest first.
    • GET /api/v1/cicd/status reports a promotion or environment for pull request checks and approval gates.
    • All three take external ids and are safe to repeat.
  • Merge commits: a promotion records the commit that merged its pull request, so a release can deploy by its commits.
  • Release references: a deployment records the release that deployed it.
  • Service accounts: an integration can act as a service account. It holds permissions through user groups like anyone else, but can't sign in and isn't billed as a seat. Client Credentials integrations with a service account can promote and deploy. See OAuth Applications.
  • Examples for GitHub Actions, Azure Pipelines and Databricks Asset Bundles.

Changed

  • A promotion's external id is now labelled Pull Request on the promotion pages, with guidance and examples, and the promotion page shows the Merge Commit recorded by your pipeline. A deployment made by your pipeline shows its Release.
  • A promotion's pull request (external id) is unique among the account's active promotions, and an environment's external id among the account's active environments.
  • Promoting a promotion that is already promoted, or deploying a deployment that is no longer pending, returns 409 Conflict instead of running it again.

2.0.0 — October 2026

Branches and Environments

TitanRDM now separates where table definitions are developed (branches) from where data lives (environments), in line with how platforms such as Databricks, Microsoft Fabric and Snowflake recommend working. See Environments and Branches.

New

  • Environments — Prod, Stage, or a developer's own Dev environment. Each environment holds its own deployed tables and data, and is deployed from one branch. One branch can deploy to several environments: by default main deploys to both Stage and Prod.
  • Environment chooser — the chooser in the header now selects your current environment instead of a branch. End users go to the Tables page after switching; developers go to the Table Definitions page, which shows the branch of that environment in a prominent pill.
  • Your own branch and environment — every developer gets a development branch and a private Dev environment, shown with their name, for example Dev (Jane Smith).
  • My Branches (Development menu) — create, edit and delete your own development branches. Each new branch gets its own environment. Deleted branches can be restored for 30 days.
  • Admin > Environments — create and manage environments, with a diagram showing which branch deploys to each environment. Admin > Branches has moved to the Admin menu and shows the same diagram.
  • Promotions create deployments — promoting into a branch creates a deployment for each environment that branch deploys to (for example Stage and Prod), which you then deploy when ready. The promotion and its deployments link to each other.
  • Promotions page tabs — one tab per target branch, each with a count of promotions waiting.
  • Deployments page tabs — one tab per environment, listing pending deployments in the order they were created, followed by the history.
  • Deployment warnings — a deployment warns you when its tables have changed since it was created (naming the later promotion), when older deployments to the same environment are still waiting, and before deploying to production. Older deployments that a later one has fully applied are marked Superseded.
  • External ids — branches, promotions and environments can carry an external id (for example a Git branch, pull request number or release stage), so your CI/CD pipeline can drive TitanRDM. See CI/CD Integration.
  • Environment permissions — each environment has an Editor group (access to the environment and its data) and a Deployer group (deploy to it). New end users get access to the production environments; new developers get access to every shared environment. The User Groups pages show the branch or environment each group grants access to. See Permissions.

Changed

  • Table Definition pages offer Promote only when the branch has a parent to promote to, and Deploy only on development branches. Environments of shared branches receive their deployments through promotions; administrators can bring an environment up to date from Development > Deployments.
  • Deployment status is shown per environment, for example Stage ✓ Prod • pending.
  • Deployment history records the user who deployed.

API — action required

  • The data endpoints (imports, exports, table data and deployed table definitions) take environment_id instead of branch_id.
  • PATCH /api/v1/environments/set_current replaces PATCH /api/v1/branches/set_current_branch.
  • Deployments are created for an environment_id, and can be filtered by environment, promotion and their external ids.
  • Promotions accept external_id and all_pending, and the promote response lists the deployments created.
  • Branches no longer have a database_suffix; environments have a schema_name instead.
  • The promote and deploy endpoint has been removed: promote, then deploy the deployments the promotion creates.

See the API Endpoints Reference.

1.2.0 — September 2026

Excel Imports

New

  • Import from Excel — imports and Import Schema accept Excel workbooks (.xlsx) as well as CSV and Parquet. See Importing Data and Import Schema.
  • Choose the sheet and range — after uploading, a preview shows the first 50 rows. Choose the sheet and the top-left and bottom-right corners of your table, either by clicking cells in the preview or by typing them, so a corner that is off screen can still be reached.
  • Grow with each file — on by default: each import reads down to the last row of the file it is given. Turn it off to fix the bottom row, for example when a sheet has a totals line or a second block of data beneath the table.

Improved

  • Column types are suggested more accurately from Excel data: whole numbers become integer, and a column whose values disagree with its first row becomes text instead of failing.
  • Dates entered as dates in Excel are imported as dates.
  • Empty columns, and columns of numbers in scientific notation, no longer produce an invalid column type.

Fixed

  • Imports started from the preview now finish with the correct status (completed or failed) instead of staying at created.
  • Imports interrupted part-way through are now cleaned up automatically and marked as failed.

Related Pages