Delphix Products

Expand all | Collapse all

Delphix 5.0 Limits

Jump to Best Answer
  • 1.  Delphix 5.0 Limits

    Posted 09-04-2016 02:06:00 PM
    What are delphix 5.0 Limits: max number of delphix objetcs, max number of VDB per dSource, max number of VDB on a host, max number of vDB, max storage size.

  • 2.  RE: Delphix 5.0 Limits
    Best Answer

    Posted 09-04-2016 04:12:00 PM

    There is a limit of 400 Delphix objects.  Within that limit, there are no limits on numbers of dSources or VDBs, VDBs per dSource, VDBs per host, or dSources per host.  The amount is storage is limited by the hypervisor or by the data platform.  For example, VMware ESX 5.x is limited to 60 storage devices per VM guest, etc.

    For the VMware platform and limits, please check VMware documentation (

    Hope this helps...


  • 3.  RE: Delphix 5.0 Limits

    Posted 09-04-2016 06:25:00 PM
    Hello Tim,
    Thanks a lot

  • 4.  RE: Delphix 5.0 Limits

    Posted 09-05-2016 02:12:00 PM
    Hi Tim.,

    We're currently working on outsourcing ~300 Oracle and ~350 SQL Server databases and looking at whether to use Delphix to manage the databases in their new environment.

    Have I correctly understood that your 'limit of 400 Delphix objects' means that we wouldn't be able to manage all our current environments within Delphix.

    Thanks for the confirmation,

  • 5.  RE: Delphix 5.0 Limits

    Posted 09-05-2016 04:33:00 PM

    My apologies, the limits cited are for each Delphix engine.  Of course, it is possible to have more than one Delphix engine, and many companies do so.

    I work with one company with more than 50 Delphix engines, managing more than 500 source databases and over 6000 virtual databases.

    Delphix professional services has a solutions architecture team that is expert in sizing Delphix engines based on past, current, and anticipated database I/O workloads.

    Outsourcing, or migrating to another data center or IaaS, are prime use cases for the foundation Delphix data virtualization capabilities, as well as the additional data transformations of data masking, cross-platform conversion, and database upgrades.

    The foundation data virtualization capability minimizes storage and time during provision and refresh, and the self-service capabilities in the hands of development and testing teams streamlines processes even faster, thus accelerating infrastructure utilization and enabling agile development, DevOps, and continuous delivery.

    Beyond that, data masking in particular is a transformation that is critical for the elimination of any security risks in any outsourcing scenario or cloud migration.

    Cross-platform conversion on Oracle is a method to escape from legacy UNIX platforms to cloud-based Linux x86 platforms.

    And, if desired, automated database upgrades are another transformation to increase DBA team efficiency in provisioning or refreshing non-production databases.

    Please let us know if more information would be helpful?



  • 6.  RE: Delphix 5.0 Limits

    Posted 09-05-2016 05:44:00 PM
    Hi Tim.,

    Thanks for the clarification.

    For licensing reasons, we only have access to one Delphix engine, so this rules Delphix out in terms of our migration.


  • 7.  RE: Delphix 5.0 Limits

    Posted 09-05-2016 06:22:00 PM

    Pardon my saying, but your expectations for a single 8-vCPU virtual machine Delphix Engine are unrealistic.

    Each 8-vCPU Delphix engine is capable of handling 800-1000 MB/s of I/O from the databases it is supporting, more if using "jumbo frames" and other optimizations.  Let's call a max of 1200 MB/s, which is 96% of line speed for 10GbE networks?

    Assuming that each of your ~650 source databases spawned only two virtual databases (which is unrealistic, usually it becomes 8-15), we're talking ~1300 virtual databases minimum.

    With an I/O capacity of 1200 MB/s to allocate among ~1950 database objects, less than 1 MB/s of I/O is being allocated for each database, if they're active the same time.  This is an unsafe assumption, as any one of those databases (source or virtual target) could clearly exceed that total at any time by itself.

    Far more likely is that those ~1950 databases will average far more than the 800-1200 MB/s cited for one engine, with peak workloads even higher than that.

    The only way to accurately quantify the necessary resources comes from observing past and current behavior, and extrapolating for the future.

    So, in summary, your limit is not the number of database objects.

    Rather, it is under-configuration of computing resources.  A single 8-vCPU virtual machine, nor an 8-core physical server, could never meet such I/O workload expectations.

    I strongly recommend sizing resources objectively based on past, current, and projected I/O workloads, to determine a viable configuration.

    Hope this helps...