2026.08LatestAugust 2026
Only build what changed
Two headlines this cycle. State-aware runs prove which models would produce the same result as last time and skip exactly those, with a reuse rate, an estimated saving, and a recorded reason for every rebuild. And your projects are now open to the AI assistants your team already uses: Claude, Cursor, or any MCP client can read your models, runs, and governed metrics, and run approved dbt commands, inside permissions you approve one by one and can revoke at any time. Alongside them, semantic definitions get a proper editor with a no-YAML Builder, and generated documentation becomes a versioned history you can browse, compare, and share as a link that stays still.
AI AssistantsState-Aware RunsNotificationsAtlas CatalogOrganizationsSemantic LayerJob SchedulingSnowflakeLanguages
New
- A Notifications hub for the whole organization. Connect the dbdeux Slack app once and pick channels from a list, then add routing rules for the alerts a single run cannot tell you about: a job still failing after the number of runs you choose, the recovery that follows, a schedule that never started, a run taking far longer than usual, a downstream refresh that did not go through, maintenance mode, catalog change requests, and account and plan events. Each rule delivers to any mix of Slack, Microsoft Teams, PagerDuty, email, a signed webhook, and the new in-app bell.
- Quiet alerts, not blind ones. Every routing rule can carry a cooldown and quiet hours; repeats and off-hours events are recorded as skipped with their reason in an organization-wide delivery history you can filter by status, event, job, environment, channel, and date. PagerDuty resolves always go through.
- One daily digest on top of immediate alerts, at the time and time zone you choose, to Slack, Teams, or email, with Send now for the mornings you want it early. And a personal Notify me on Slack card where each member can opt into direct messages when their job fails, a request lands on their desk, or a model they own changes, with a test DM to confirm the match. Tick several events at once to create matching rules in one pass, and watch your routing-rule allowance on the card itself.
- Owners of a catalog object now hear about it. A new catalog version that changes a model you own, a pull request build that fails on it, or a question asked about it reaches its Business and Technical owners by email and Slack, with exactly what changed. Each person chooses which of the three they want in User Preferences.
- Ask the owners directly from the object. Every catalog entry has Ask a question and Request a change from the owners, and the resulting thread lives on the object with replies and an Open, In progress, Resolved, or Declined status, so the answer becomes documentation instead of a chat message that scrolls away.
- Snowflake connections speak your identity provider's language. External OAuth signs in to Snowflake as an application registered in Entra ID or Okta, works everywhere a key pair does (scheduled jobs, pull request builds, the Semantic Layer, AI assistants), and can be switched off centrally without touching Snowflake or dbdeux. The connection drawer carries the full setup guide.
- On a developer sandbox, each developer connects to Snowflake as themselves. Snowflake OAuth gives every person their own sign-in, with connected-as and expiry shown on the connection, a 90-day session with one-click reauthorize, and privileged roles kept out by design.
- Job run history has a long memory. Finished runs stay in recent history for at least 90 days (longer on higher plans), then move to a read-only archive where every run still opens from its link, with its log, so the recent view stays quick and the record stays complete.
- Notify on test warnings. A test marked severity: warn gets its own notification gate, so a stale feed or a soft quality rule reaches the team while the run keeps going and the build stays green.
- Invite people who have never used dbdeux straight from Organizations > Members: type an email, pick a role, and they receive a link to set their password. The membership becomes active with exactly that role the moment they first sign in, so a pending invitation is a promise rather than access. Nobody can invite above their own role, invitations expire and can be resent or revoked, and every one stays on record with its delivery status and an audit entry.
- Name a future teammate as a catalog owner before they have an account. Type their email into the owner picker and they are invited and pencilled in as owner in one step, shown as an invited chip until their first sign-in turns it into a real owner. The person who actually knows the model can be its owner on day one.
- Every catalog object can now name its owners, and they are two different people: a Business owner for what it means and a Technical owner for who fixes it. Owners are real organization members picked from a search, adopted in one click from the ownership hints already in your dbt meta, groups, and exposures, or assigned to a whole selection at once from Browse. Names appear on share links, contact details never do.
- Ownership rules for large projects: give every object in a folder, a modeling layer, or a dbt tag a default owner and the rule re-applies on every new catalog version, so a model added next week is owned the moment it lands. Inherited owners are labelled with the rule that assigned them, hand picks always win, and a rule you delete takes back only what it assigned.
- Ownership coverage joins documentation and test coverage: an ownership ring with a business and technical split, a per-layer breakdown, an Unowned list you can bulk-assign or cover with a rule in one step, and a clear count of objects whose only owners have left the organization, so succession happens before an incident rather than during one.
- AI assistants can now work with your projects directly. Connect Claude, Cursor, or any MCP client from the new MCP Server tab and it can explore your models and lineage, read how last night's run went, ask a governed metric, and run approved dbt commands, instead of guessing at table names it has never seen.
- Sign in to connect, and the assistant acts as you: it sees what you can see and is refused what you would be refused. A consent screen lists every permission it asked for, and you tick the ones you are willing to grant. Anything you left unticked does not appear in its tool list at all.
- Read-only SQL, on your terms: with your approval an assistant can run a single read-only query as you, with your connection access rules, a row cap, and a timeout. It is available only to signed-in connections, never to a shared token, so warehouse data is never reachable by an unattended credential.
- Your connected assistants, in one list: what you authorized, what it may do, when it was last used, and a Revoke that ends its access immediately. Every assistant action is attributed in the audit log, by your name for a sign-in and by the token name for a service account.
- Assistants answer metric questions from your published semantic definitions rather than writing their own SQL, so the number an assistant gives back is the number your dashboard gives back, and the question lands in query history labelled as coming from an assistant.
- Maintenance mode for jobs: pause a whole workspace's schedule in one action with a reason your teammates see and a duration that ends it automatically. Scheduled and chained runs are recorded as Skipped rather than quietly missing, in-flight runs are never cancelled, every job shows as Frozen, and an owner can still force one urgent run with a recorded override.
- State-aware runs: stop paying to rebuild models that have not changed. Before a scheduled run executes, dbdeux fingerprints every model from its compiled SQL, its configuration, its parents, and your warehouse's own freshness metadata, then skips only what it can prove is identical to the last successful run. Anything unprovable rebuilds, so a state-aware run is never less correct than a full one.
- Clone restore instead of rebuild: a model whose fingerprint matches but whose table is missing from this environment is restored by clone rather than recomputed. Zero-copy on Snowflake and BigQuery, deep clone on Databricks, which makes standing up a fresh staging environment minutes of metadata work instead of hours of compute.
- State-aware runs now cover nine warehouses. Snowflake, BigQuery, and Databricks report when data last changed, so any model can be proven unchanged. Redshift, PostgreSQL, MotherDuck, Microsoft Fabric, Azure Synapse, and Athena prove reuse for models built from seeds and other models, and rebuild anything fed by a source rather than skipping it on an assumption. Every other warehouse runs exactly as it would have.
- Warehouse capability on the State tab: instead of a table you have to find yourself in, the tab reads the warehouse the environment is connected to and says in one line what reuse can do there, so expectations are set before the first run rather than inferred from a disappointing reuse rate.
- State analytics per environment: reuse by day, node outcomes, reuse rate, estimated time saved, and top models by savings over a 7, 30, or 90 day window, so the value is a number rather than a claim.
- Why models rebuilt: every rebuild records its reason in plain language, from "Model changed since the last run" to "SQL produces different results each run" and "Cannot tell if source data changed", each with an explanation of what it means and what to do about it. Reuse being lower than you expected is now a question with an answer.
- Choose your engine: DbDeux State runs natively against your own warehouse with nothing to buy and no metadata leaving your account, or opt in to dbt Labs' hosted dbt State if you already have it. Analytics keep each engine's history separately so you can compare them on your own project.
- Post-run actions can fire on success with data changes, so a dashboard refresh or a notification happens on the nights that produced new data and stays quiet on the nights that did not.
- Semantic model editor: one definition, three ways to work on it. A form Builder for datasets, relationships, metrics, and hierarchies with no YAML required, a full YAML editor with completion and inline validation, and Edit with Atlas, where a sentence becomes a diff you review before anything is written. Your comments and untouched fields are preserved either way.
- Definition history and restore: browse the commits that touched a semantic file, view any earlier version, and restore it as a reviewable working change. Save validates first, and publishing stays a separate, deliberate step.
- Catalog versions and history: every documentation generation publishes a version instead of overwriting the last one. Filter by environment, browse any earlier version with a banner telling you which one you are reading, and compare two versions to see exactly which models, columns, types, descriptions, and tests moved.
- Share links pinned to a version: pin a documentation link to an exact published version so a data contract, board pack, or audit response keeps showing the same thing after your team regenerates docs. A version an active link points to is always kept.
- Atlas file and folder attachments: pin the files or whole folders you want considered, see them as removable chips, and keep them attached across turns. Attachments are read at send time, so Atlas sees your uncommitted edits.
- Measures in the Semantic Layer: the raw numeric fields metrics aggregate over are now first-class, so it is clear where a number comes from, and every metric can be read as either a business definition or the exact compiled query.
- Snowflake programmatic access tokens: connect an MFA-enforced Snowflake account without disabling a security control or setting up keys. The token keeps the role restriction and expiry you gave it.
- Clone a job: copy a working job, adjust the copy, and resume it when it is ready. Clones start paused so a copied schedule cannot fire while you are still editing it.
- Every Slack message and email now carries a View run in dbdeux button that opens the right workspace, the right job, and that exact run's log in one click, however old the run is. Job pages keep their address, so a run link pasted into a ticket lands a teammate on the same run.
- Post-run action outcomes on every run: a timestamped log of what fired, what was skipped and why, and what failed with the response it got back. "The dashboard did not refresh" is now answerable from the run itself.
- Generate docs on run: tick one box on a scheduled job and your documentation refreshes after every successful build, publishing a new catalog version each time. Documentation stops being something someone has to remember, and a docs hiccup never turns a successful run into a failure.
- Semantic query history: every metric query the project runs is recorded, whether it came from the catalog, a saved query, GraphQL, or an AI agent, with the metrics and grouping asked for, the SQL generated, the timing, the row count, and the catalog version it was answered from. Failed attempts are kept with their error, which is the half most tools throw away, and any entry can be replayed with one click.
- GraphQL access to the Semantic Layer: tools and front ends that already speak GraphQL can discover metrics and dimensions, list saved queries, and run a metric query in a single request, pinned to the branch and published version they choose.
- dbdeux now speaks your language. Pick English, French, German, Spanish, Portuguese (Brazil), Hindi, Bengali, Russian, or Arabic under Language in your preferences and the interface changes immediately. Each language is listed in its own name, Arabic lays the interface out right to left, and the choice is yours alone rather than something set for the whole team. Your models, columns, and descriptions stay exactly as your team wrote them.
- Your first visit already speaks your language: dbdeux honors your browser's preferred language before you choose anything, and the first time it does, a notice in that language offers Keep or Use English so the automatic choice is always a visible one. The guided tour gained a Language step so new teammates learn where the setting lives in their first minutes.
Refined
- Come back to a tab you left open this morning and it picks up where you were: an idle session signs itself back in quietly, keeps the workspace you had selected, and every part of the app, from the editor to a running job's live log, carries on without a sign-in screen or a stale error in the way.
- Each job has an Activity tab: every edit and every run in one timeline with the person or API token behind it, and one click opens the full Audit Log pinned to that job and its runs. Runs started through the API are labelled as such in the runs list.
- Job statistics follow the window you care about: Today, Yesterday, and the last 7, 31, 60, or 90 days, with success rate, duration, and the runs list all recomputed for the range you pick.
- Existing Snowflake password connections show a switch-by date and a Deprecated auth pill on the Databases list, and switching to Key Pair or a Programmatic Access Token changes only the credential: account, user, warehouse, database, schema, and role are kept. New Snowflake connections start on a key, a token, or OAuth.
- A link opened while signed out takes you to that page after sign-in, whether it points at a run, a catalog object, or a Semantic Layer definition, so a shared address lands where it was meant to.
- The metric catalog leads with business names and keeps the technical name underneath, browses one file at a time or all at once, explains each section in plain language, and remembers how wide you like the rail.
- Runs and Jobs are far easier to search: filter runs by environment or environment type, search across job, tag, project, environment, and person in one box, and find jobs grouped by the environment they target. Run now reports its real state as it happens rather than leaving you guessing.
- Warehouse re-scan in the editor: the refresh control now separates redrawing what is already known from going back to the warehouse for objects that did not exist at the last scan, so a missing table is never a mystery. Snowflake scans are substantially faster.
- Re-scan a single schema instead of a whole connection, so picking up one new table on a warehouse with hundreds of schemas takes seconds. If a scan is already running, dbdeux says so rather than stacking another on top of it.
- Post-run actions guide you to Integrations when you have no credential set up yet, so the path from an empty list to a working refresh is one click, and a job summarizes its refresh targets with a tooltip naming every workspace and model.
- Projects hosted by dbdeux work the same everywhere: connection tests and scheduled runs use the project files directly, with no Git branch to resolve and no wording implying you need a repository.
- Creating a project now shows the workspace it will be created in, and lets you change it in place. The setup checklist ticks items off live as you complete them.
- Copy results the way you meant to: an explicit right-click menu for cell, row, column, selection, or the whole table, with or without headers, plus CSV, JSON, Markdown, and SQL INSERT so results paste cleanly into a spreadsheet, a ticket, a pull request comment, or a seed file with no reformatting.
- Power BI targets are picked by name from the workspaces your credential can see, rather than looked up elsewhere and pasted in as identifiers, and selected targets read back as names.
- Testing a connection you are editing now uses the values on the form, so a changed account or role is verified before you save. Blank secret fields keep the stored secret, and the test saves nothing.
- The Semantic Layer names the branch it is reading, and follows the branch a generated definition was added to, so new metrics are on screen instead of appearing to be missing.
- A Default project preference decides which project pages open on in a workspace with nothing remembered yet, or keeps returning you to where you left off.
- Environments can carry a description, shown in the environment header and as a hint on the selectors where you pick one, so a project with several similar environments explains itself at the moment of choosing.
- Result grids select like a spreadsheet: click a row number, right-click a column header, or click the corner cell, then use Ctrl+C. What is highlighted is exactly what gets copied, and the confirmation names it. Table copies are comma-separated so pasted results still read as a table wherever they land.
- The Atlas attachment picker leads with the file name and shows its folder underneath, with the full path on hover, so picking the right file out of a deep project takes a glance instead of a squint.
- Atlas writes column names exactly as your warehouse reports them, quoting case-sensitive columns, and merges into a schema file that already documents some columns without creating a duplicate entry.
- Integration credentials are visible to everyone in the organization so a teammate can reference the connection you set up, while editing or deleting stays with the owner or an organization owner or admin.
- Shared documentation portals state which environment the docs came from and present curated references read-only, so a recipient always knows what they are looking at.
- Applying an Atlas change now creates the files and folders the proposal needs instead of asking you to make an empty file first. The review step is unchanged, so nothing is written until you apply it.
- Run just the statement you are working on: Cmd+Enter runs what you highlighted, or the statement your cursor is in, so a worksheet can hold a whole set of related queries and you run them one at a time from the keyboard.
- Query results stay on screen when you leave the editor and come back, with the same rows and result tabs, and nothing re-executed against your warehouse to restore them.
- Select top 100 in editor: right-click any table in the Database Explorer to open a ready-to-run worksheet in that connection's dialect, and browse a tree ordered plainly by name instead of however the warehouse returned it.
- The dbt Cloud migration tab now hands you the export tool with a Download the CLI button and the exact commands to run, accepts the manifest by drag, file picker, or paste, and sizes the move up front: how many projects, environments, jobs, and secrets to re-enter, with the dry-run plan filterable by what will be created, skipped, unsupported, or needs a secret.
- Environment edits are harder to lose: an Unsaved changes marker in the header and a save bar that stays in view as you scroll, so Save is reachable from anywhere in a long form.
Dependable
- Deleting a workspace shows exactly what lives in it first, and stops with a named list while warehouse connections remain, so credentials and the jobs relying on them are never left stranded.
- Every commit accounts for every staged file. If a file cannot be included, it is named for you and stays in the Changes panel, so the count you committed and the work still waiting always add up.
- Change indicators in the file tree and on the Changes button read the same Git status the panel does, so a file saved back to its original contents is clean again, a folder clears once the work inside it is committed, and being behind the remote reads as its own state.
- A long session ends on your terms: an Are you still working? prompt counts down and returns you to the same page when you continue, with any open dialog work intact. A Sign out button on the same prompt ends the session everywhere at once, which is the right move on a shared machine.
- The log of a run that has already finished waits for its full output, so the log of an overnight build is there when you go looking for it.
- Restricted connections stay enforced when nobody is watching. A scheduled job or CI run is checked against its owner's real organization role, so an admin's overnight job keeps working and access is refused to everyone it should be.
- Run output explains a project variable that refers to itself, naming the cause and the two ways to resolve it, rather than reporting a parsing problem you have to decode.
- Shared documentation reads accurately at a glance: every timestamp is shown relative to now, and a connection whose workspace has been removed is clearly marked.