Simple Talk is now part of the Redgate Community hub - find out why

If unexpected database changes cause you problems – we can help!

Have you ever been surprised by an unexpected difference between you database environments?

Have you ever found that your Staging database is not the same as your Production database, even though it was the week before?

Has an emergency hotfix suddenly appeared in Production over the weekend without your knowledge?

Has your client secretly added a couple of indices to their local version of the database to aid performance?

Worse still, has a developer ever accidently run a SQL script against the wrong database without noticing their mistake?

If you’ve answered “Yes” to any of the above questions then you’ve suffered from ‘drift’. Database drift is where the state of a database (schema, particularly) has moved away from its expected or official state over time. The upshot is that the database is in an unknown or poorly-understood state. Even if these unexpected changes are not destructive, drift can be a big problem when it’s time to release a new version of the database. A deployment to a target database in an unexpected state can error and fail, potentially delaying a vital, time-sensitive update.

A big issue with drift is that it can be hard to spot and it can be even harder to determine its provenance. So, before you can deal with an issue caused by drift, you’ll need to know exactly what change has been made, who made it, when they made it and why they made it. Those questions can take a lot of effort to answer. Then you actually need to decide what to do. Do you rollback the change because it was bad? Retrospectively apply it to the Staging environment because it is a required change? Or script the change into version control to get it back in line with your process?

Red Gate’s Database Delivery Team have been talking to DBAs, database consultants and database developers to explore the problem of drift. We’ve started to get a really good idea of how big a problem it can be and what database professionals need to know and do, in order to deal with it. It’s fair to say, we’re pretty excited at the prospect of creating a tool that will really help and we’ve got some great feedback on our initial ideas (see image below).


We’re now well underway with the development of our new drift-spotting product – DLM Dashboard, formerly SQL Lighthouse – and we hope to have a beta release out soon. What we really need is your help to shape the product into a great tool.

So, if database drift is a problem that you’d like help solving, find out more about the beta and see if you’d like to sign up.

How you log in to Simple Talk has changed

We now use Redgate ID (RGID). If you already have an RGID, we’ll try to match it to your account. If not, we’ll create one for you and connect it.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.


Simple Talk now uses Redgate ID

If you already have a Redgate ID (RGID), sign in using your existing RGID credentials. If not, you can create one on the next screen.

This won’t sign you up to anything or add you to any mailing lists. You can see our full privacy policy here.