Some modern databases provide agility for DevOps teams to realize their goals quickly. The question for IT managers to consider is: What aspects of a database should be dynamic so that my DevOps team will have maximum velocity?

To stay competitive, release cycles must be as agile a process as possible. Organizations that can respond with agility to changing needs gain and keep customers, reduce overall costs, and improve customer experience. The database serves as the foundation of your software, but many databases are as adaptable as cement.

Organizations that minimize obstacles to DevOps velocity can quickly release improvements and respond to their customers’ needs. Traditional databases are as bendable as cement, which slows release cycles and discourages feature adaptations. Some modern databases provide more flexibility for DevOps teams to realize their goals without sacrificing efficiency. This article is based on Oren Eini’s article Getting Your Database Onboard with DevOps. The agile DevOps principles described in it are the basis for how RavenDB is designed.

Get started quickly

Classic databases can take a lot of time to get into production, costing organizations time and valuable resources. Organizations need time to migrate their data, get started, and scale to predicted IO needs. RavenDB is designed with the flexibility and self-optimation to get you from planning to production quickly. RavenDB Cloud servers are secured by default and on-premise servers each require a few clicks in RavenDB’s Setup Wizard.

If you already have a secure cluster set up and a database running in production, starting a new database for a development/release cycle with RavenDB only requires a few clicks to create a new database from a recent backup. Then you toggle encryption, and select which nodes to add to the database group for failover and distribution of work. A few minutes, and you’re ready to try out your ideas for the next release.

Security

Since 2017, hundreds of thousands of servers have been hacked every year. Redis, MongoDB, and Elasticsearch each had over 100,000 data breaches in 2022 alone. Setting up security quickly from the start of a development cycle is crucial to ensure that the database isn’t accidentally left exposed when it goes into production. It usually takes many days to patch an exposed database in production, leaving plenty of time for hackers to get in. How many DevOps professionals want to go into production only to find a security error or that they forgot to set up encryption before releasing? A DevOps-friendly database makes it quick and easy to set up industry-standard security from the start of every release cycle. RavenDB has top-notch security by default in the cloud and only takes a few minutes to set up on-premise servers. Also, DevOps teams cannot expose an unsecured server to the public intenet without explicitly choosing to.

A flexible structure

The form, scale, and depth of information organizations can take in is evolving too fast to be chained to a “set and forget” style of classifying your most important asset. Databases that offer a flexible schema make changing easy. But how do we organize unstructured data? RavenDB indexes map the dataset according to the fields that you define. Our indexes give structure to unstructured data and stay updated whenever the data changes. You can choose to add a reduce phase and RavenDB will summarize the data for you. You can also have the indexes run various computations instead of your queries. Our indexes do the work that queries usually do, and they do it incrementally behind the scenes, making queries much faster and saving tons of I/O costs!

Relational databases require users to define a schema for their data as the very first thing they do. This is the worst possible time to cement your systems – when you know least about your project and how it will need to adapt to changes. Making changes to this schema is possible, but it’s awkward and expensive. Too much time needs to be spent making sure that schema changes are versioned, deployed, and managed.

This creates a strong incentive to avoid changing the schema, turning the need to become agile into an obstacle to getting the most out of the available information. Responding to your customers’ feature requests or opportunities of new data sources is much less cost-feasible with a relational database. Changing the schema in a relational database puts the brakes on the velocity of your release cycle, delaying your launch of new features and getting your product to market.

A flexible schema database lets users change the very foundations of their platform instantly. The next release can be remodeled to use more focused data without wasting time rebuilding half of a user’s application. This gives users the best version faster, and at the same time, benefits organizations by giving them better means to adapt and grow. Flexible data structures accelerate agile software development cycles to rapidly improve a product in response to its users’ requests.

Why Should You Have to Choose Between Agility and Efficiency?

Fewer trips to the server means better efficiency

Going to the server for every request is like wanting a sandwich and going to the store for a slice of bread, then going back for a tomato, and so on. RavenDB users typically serve between 1000 up to 1,000,000 transactions per second. That is why RavenDB is designed to batch a bunch of requests in each trip to the server. Your users won’t feel this because the client still makes many trips every second.

RavenDB is unique in the NoSQL world in that its ACID transactions are default and at over 1M transactions per second, do not penalize data integrity. How is RavenDB so efficient? Our approaches to client-side caching, batching, lazy requests, advanced indexing, query projections, and including related documents in each trip to the server add up to incredible ACID performance at costs so low you need to try it to believe it.

Making sense of heterogeneous, unstructured data

RavenDB has native various nimble indexing capabilities so you can effortlessly organize, run computations on, and summarize heterogeneous, unstructured data incrementally as the dataset changes. RavenDB indexes do all of this work behind the scenes, so that when you query the index, you can generate reports on huge datasets and feed your clients with processed data at trivial costs and latency.

Even complex queries on such indexes usually return the requested data in tens of milliseconds. To contrast, SQL queries that have to cross multiple joins can take thousands of milliseconds. Most NoSQL databases do not force queries to use indexes, which looks fine in tests on small datasets, but in production it can take far longer than thousands of milliseconds. Such slow queries are frustrating for users and can cost lots of money in I/O cloud processing.

Dynamic / Auto indexing

When a new release is created, users create new queries to their data. As a result, with most databases, they have to create new indexes to speed up the queries. Not using an index means each query will need to scan the whole dataset, which can be a lot of work. A database like RavenDB with dynamic indexing will always use an index for every query. It employs self-learning by automatically setting an index up, using an existing one, or updating an existing one. Auto-indexes are removed if they’re not used. This saves the development team the time needed to anticipate and make new indexes. The alternative is slow, costly queries or putting up an unnecessary obstacle to your next release by having someone analyze each and every query imaginable.

Rich feature-set

Technical issues are the landmines of the DevOps process. You never know where they are and when they go off, but there will be damage. If most of your system’s features are native, you only need to go to one place to resolve your issues. That can save lots of time and effort. If you have a solution using various third-party components, you might need to go to several places for help, often hearing the support engineer say, “This is not our problem. Talk to the people who developed the other component.” Many RavenDB use cases don’t need more than RavenDB, though integrations are available for SQL, OLAP, Kafka, RabbitMQ, and Grafana.

Scalability in both directions

For any application, there are seasonal peaks and valleys in traffic and overall usage. Any retail app needs to expand its capacity for Black Friday, while most educational offerings can contract a little for the summer. Organizations need something that can quickly adapt. The right database lets users scale out or up fast enough to keep the next release on schedule. This can also save money if you are on the cloud and have to pay for the memory you use, even if it is a slow period.

Multiple nodes for multiple versions

A distributed database cluster lets you pass the baton while both of you are running. On a database cluster of multiple nodes, you can incrementally deploy your application, updating the data you store to the database along with the old versions of your application. It will work just fine with the new data, not missing a beat or dropping any datum to the floor. It’s a great way to test out what’s working and efficiently switch over to the next version.

In-memory integrated and unit testing

A database should have the ability to run development tests in isolated in-memory mode. You can create a database in-memory, and it will act like a database gone live without touching the disk. Data won’t be persisted. This lets you set up tests, perform them, and do it as many times as you need quickly and efficiently without having to clean up and reset the data after every test. Testing while still in flight is a database must for a well-oiled DevOps process. To simplify your testing process, RavenDB offers in-memory testing for unit and integrated testing.

In summary

Application developers are looking at every part of the release cycle for ways to increase the velocity at which their applications are brought to market. Traditional databases were classically untouchable for enhancement. RavenDB — schemaless yet ACID, instantly scalable, distributed, has high performance and low I/O costs, and saves developers’ time spent with tedious database tasks — provides many advantages in quickly providing your customers with the features they need. RavenDB is also safe and performant by default – our users have peace of mind and go to sleep with their phones off.