If you could give every developer a copy of the database, would you?

The simple truth is that databases can’t be given to every developer like source code.

Databases can be large, complex, and extremely difficult to copy. It is rare to see developers or even development groups that have a copy of the full production database to use for their tasks.

On the other hand, developers almost always have access to a full copy of the application code stack. Source control methods like git make it easy to clone, fork, and track code from the component level to the entire codebase.

For databases, the typical strategies are:

1. Share a full copy of the source database across a group
2. Provide small subsets of data from the source database to developers
3. Allocate schema only ‘databases’ per developer

Each of these strategies presents their own problems.

Sharing a database across a group of developers means that any change one developer makes can impact the other developers. There is no automated way to protect a group of developers from the changes of a single developer. To protect development problems that can be caused by new changes, the changes have to be reviewed. Reviews can take up to a couple of weeks, meaning the coder who wants to implement these changes has to wait. The first in a long line of delays as a result of inadequate database resources.

If developers are given subsets of the database (partial copies, only some data) or empty skeleton schemas, it will easily lead to code that has not been tested on the full range of data that is present in production. This of course opens the door to untested bugs born from outliers in the data and queries that are not optimized on the full set of data. Finding these bugs late in the development cycle is more costly by far than finding them immediately with the developer writing the code.

With Delphix you can........

Version data like code

How does it work?

According to one of our customers...

"Delphix maintains a continuous streaming backup of our production databases and allows us to create as many full copies as we want.  Copies can be masked or unmasked and are created in minutes, using minimal storage.   Delphix enables us to deliver projects faster whilst saving us time and money.”

Problems with Storage Snapshot based DaaS

Storage Snapshot Cloning Architecture

Customer issues with Storage Snapshot based Cloning

Many customers have mentioned several common problems with their existing storage snapshot based cloning solutions.

To make clones from storage snapshots you must have a full copy of the source database.   It must be a copy because you don’t want to create storage clones on your production storage array and potentially compromise performance.  It must be a full copy because that’s how storage snapshots work.

The major problem here is that you need a mechanism to maintain this full master copy on a different storage array.  Using database vendor specific replication technologies will require you to establish and maintain a variety of solutions if you use more than one database vendor, so most customers use storage replication.  However storage replication does not guard against physical or logical corruption making its way to the replica copy, that might have been avoided using the database vendor replication methods.  In addition we are now locked into the storage vendor for replication, snapshots and clones.

The next issue is that the performance of storage snapshots tends to decline quite rapidly.   Some customers are forced to periodically instantiate new master full copies just to restore performance.   So now we have maintenance, availability and a storage overhead issue.

Finally most storage snapshot solutions do not have automated maintenance workflows to cover the three main requirements for DaaS which are synchronization, governance and provisioning.   For many customers this makes their storage snapshot based cloning solution non-scalable from an operational and performance point of view.

How is Delphix Different

Ø  Delphix is storage agnostic

Ø  Delphix does not require a full copy of the source database(s).

Ø  Delphix automatically synchronizes with source database and retains a compressed de-duplicated copy.

Ø  Delphix can validate the integrity of the Delphix maintained copy.

Ø  Delphix works the same for all supported databases.

Ø  Delphix reduces the workload on the underlying storage by minimizing storage IO.

Ø  Delphix automates the entire DaaS workflow end-to-end.

Ø  Delphix provides self-service interfaces for operational and end-user teams.