NoSQL is not the first database technology to provide powerful new data management capabilities that make people question the role of relational databases. In the 1990s, object databases were touted as the way to store data in a format that more naturally fit object-oriented languages. However, object databases were too closely tied to specific object-oriented languages, so accessing data in a flexible manner was difficult. Object databases fell out of favor and object-relational mappers gained popularity. A decade later, XML databases became the rage, providing flexible storage for XML-based applications. Relational systems soon adopted XML storage capabilities, and pure XML databases faded away.
As the range of data types increase and loads began to explode, companies required database solutions management solutions that were more flexible than relational databases. NoSQL solutions emerged. They were developed to support fast, simple queries, auto-sharding, and flexible schemas. Many companies need these qualities for specific use cases. But as we’ve seen in the past, relational databases have already begun to adopt NoSQL capabilities as well as ways to work with other NoSQL solutions. Postgres, for example, supports JSON, which gives developers the ability to create document stores in the database. Postgres also has a feature for combining data from external data sources.
Developers now have a range of options to choose from when writing applications:
- Pure Relational Model: Traditional model with rigid schemas where every data value requires its own column. You can imagine how this becomes cumbersome as companies quickly expand, add new products, or new supply chains. Each item related to their operations likely has many attributes, and each of those must have a column with a specific data type. This becomes especially complicated when items differ greatly and you’re combining information in a table for (i) candy – calories, expiration dates, and ingredients, with (ii) lawn mowers – horsepower, motor components, and warranty information, and making decisions about which information should have which data type.
Developers working on traditional applications, like accounting or order entry, with fixed entry, a fixed model, or a great deal of concurrency tend to rely on the pure relational model.
- Relational Database with NoSQL Enhancements: With the ability to support JSON, Postgres is much more flexible. JSON can represent multiple kinds of data. However, because it’s still stored in a relational database, JSON data is ACID-compliant (atomicity, consistency, isolation, durability) and can be queried with SQL and combined with data in transactional tables. This provides a great deal of flexibility and freedom from the rigidity of the pure relational model. However, the transaction overhead may be higher than you want for some uses cases. For example, there’s a 28-byte row overhead for Postgres. If you’re collecting remote sensor data and there’s a 2-byte storage requirement for temperature or similar kind of Internet of Things reading, you may not want the additional overhead, especially if all you’re doing is storing the data in a schemaless structure.
Developers who need reliability and concurrency and work for organizations that are nimble and move quickly can benefit from using a relational database with NoSQL enhancements. Applications for these solutions can more easily be adapted as changes happen.
- Relational with NoSQL Storage Connected to Postgres Through Data Adapters: There continue to be use cases for NoSQL solutions like Hadoop for storing data collected at high velocities or stored in very high volumes. Postgres has a feature called Foreign Data Wrappers that connect external databases to Postgres so that database administrators can combine and work with the data as if it were all a single database. EnterpriseDB® (EDB™) has invested in this technology to develop Data Adapters to make this feature easy to deploy so companies can connect their Postgres databases to NoSQL solutions like Hadoop or MongoDB and combine NoSQL data with their relational data for more flexibility and easier analysis
Developers attracted to using a relational database with NoSQL enhancements typically have two kinds of data: 1) data that best is stored in a relational fashion, and 2) data with a high ingestion rate that may be less critical, such as website comments, that do not require relational constructs.
Pure NoSQL Model: Some companies require fast, simple queries, and auto-sharing and can absorb the drawbacks, including the loss of durability. Applications can be written to provide some protection but there are risks, as the database cannot hold stored procedures, as Postgres can, and each application requires its own database, resulting in silos.
NoSQL databases are the best fit for developers with low criticality, very atomic data they just need to store, such as log files, clickstream data, Internet of Things data, game statistics, etc.
What’s important is that developers have a choice today. NoSQL solutions continue to have their advantages but what’s emerging is a multi-model database approach. Developers now must determine what parts of an application can benefit from relational data pools and which parts can benefit from NoSQL, and then write applications to take advantage of these technologies.
While the open source database ecosystem has advanced, so too has hardware to support development and production environments. EDB Postgres on IBM’s OpenPOWER LC servers with POWER8 provides users a level of performance comparable to x86 while using fewer cores. OpenPOWER LC systems also allow organizations to save money on the price of per-core EDB Postgres annual subscriptions, with 80% percent better price-performance over x86 options, guaranteed. For more information, see Why Innovative App Developers Love High-Speed OSDBMS.
Bruce Momjian is Senior Database Architect at EnterpriseDB, a co-founder of the PostgreSQL Global Development Group, a PostgreSQL Global Development Group Core Team Member, and a PostgreSQL open source project Committer.