{"id":2831,"date":"2017-02-24T22:16:24","date_gmt":"2017-02-25T06:16:24","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=2831"},"modified":"2025-06-13T18:46:24","modified_gmt":"2025-06-14T01:46:24","slug":"nosql-simplifies-database-devops","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/nosql-simplifies-database-devops\/","title":{"rendered":"NoSQL Simplifies Database DevOps"},"content":{"rendered":"

Does your organization want to simplify Database DevOps?
\nIs your database becoming a bottleneck\u00a0to innovate rapidly?
\nDo you want to save millions of $$ in database licensing cost?<\/p>\n

Read on!<\/p>\n

State of Database DevOps<\/h2>\n

State of Database DevOps<\/a>\u00a0is a survey on DevOps adoption rates among SQL Server professionals. Over 1000 SQL Server professionals responded to the survey. The respondents came from across the globe and represent a wide range of job roles, company sizes and industries.<\/p>\n

There are some good findings in the survey results. A few key findings worth highlighting here:<\/p>\n

the greatest challenge with integrating database changes into a DevOps process would still be synchronizing application and database changes<\/p><\/blockquote>\n

Another one …<\/p>\n

The greatest drawback identified with traditional siloed database development is the increased risk of failed deployments or downtime when introducing changes. This is closely followed by slow development and release cycles and the inability to respond quickly to changing business requirements<\/p><\/blockquote>\n

And another one …<\/p>\n

Increasing the speed of delivery of database changes and freeing developers up to do more value added work are the key drivers for automating the delivery of database changes<\/p><\/blockquote>\n

The challenges highlighted here are not mentioned in the context of\u00a0SQL server only, but would be applicable towards\u00a0any relational database. You may be using Oracle, Postgres, MySQL, MariaDB or any other relational database for that matter\u00a0and would be very much facing these issues. Why?<\/p>\n

Why is Relational not well suited for\u00a0Database DevOps?<\/h2>\n

It’s common for an application to operate on data from multiple tables in a RDBMS. For example, placing an order may use Customer, Order and Product tables. Each table has multiple columns with standard data types specific to a database. Tables may have primary, reference and foreign key constraints. Developers building applications using a relational database typically use an Object Relational Mapper (ORM), such as Hibernate or Java Persistence API for Java developers. There are similar ORM for other languages as well. ORMs captures the underlying complex database structure and allow programmers to build applications naturally using their language.<\/p>\n

ORMs also use a persistence provider and allows your application to be independent of the underlying database. This persistence provider creates a binding between the language specific class to the database structure. For example, it maps a class to a table or multiple tables, binds the language data types to the types defined in the database and captures the relationship between tables. Theoretically, a programmer can use a different persistence provider to use a different RDBMS for the application. But this is far from a practical experience!<\/p>\n

Any database change requires the ORM classes to be updated otherwise the application may not work. For example, adding a new table may mean a new Java class or updating an existing class. Change of a data type in a column requires the class definition to be updated otherwise the application will not even compile. Adding a new column means adding a new field in the class. Any change requires the classes to be updated and the application needs to be repackaged.<\/p>\n

Changes in database structure are required all the time to meet the evolving needs of business. But if the DBAs make a database change and the ORM classes are not updated then there is a disconnect. Application deployment needs to be coordinated with the updating the database schema. There are tools like Flyway<\/a>, Liquibase<\/a>\u00a0and others\u00a0that integrate application and database deployment. But developers are often not allowed to make any direct changes to the production database. A disconnect would result in your application not working and the business to suffer. DevOps practices can definitely help solve these issues as it requires a close collaboration between developers that are building applications and DBAs that are updating database scripts.<\/p>\n

But as the survey reports, more than 50% of the respondents do not have DevOps adopted today.<\/p>\n

\"Database<\/p>\n

There are challenges even if you were to integrate database changes into a DevOps process.<\/p>\n

\"Database<\/p>\n

Synchronizing application and database changes where the ORM classes need to be synchronized with the backend database structure is the biggest challenge. DBAs may want to structure the database in a certain way which may not be optimal for application development.\u00a0Applying consistency across application and database development is the next major challenge for ensuring a seamless database DevOps.<\/p>\n

A siloed development has serious issues on your ability to rapidly innovate and deliver value to your business.<\/p>\n

\"Database<\/p>\n

As shown in this image, failed deployments when introducing changes, slow development\/release cycles and inability to respond to business needs account for over 60% of the drawbacks.<\/p>\n

Speed of delivery of database changes is the biggest concern for database DevOps.<\/p>\n

\"Database<\/p>\n

So what do you do?<\/p>\n

How does NoSQL simplify\u00a0Database DevOps?<\/h2>\n

NoSQL document database helps to simplify database DevOps!<\/p>\n

How does NoSQL simplify database DevOps?<\/p>\n