In database category race, candidates turn non-partisan

During this election season, we can reasonably agree on the polarized state of society, at least in the United States. But that situation is regrettable and, in technology, adversarial orientation has even less justification.

The database world ought not be partisan, nor should it be monolithic. The Internet, and building systems for it, has taught us that requirements vary between -- and even within -- organizations.

Eventually the different camps need to moderate, harmonize and, essentially, merge. They can and do have different strengths, but they need to fit together along a spectrum, rather than segregate into factions.

And, yes, I really am talking about databases here. Specifically about so-called NoSQL databases and relational database management systems (RDBMSes).
What happened?
Almost eight years ago, the term NoSQL was coined, describing a new class of database. Products and open source projects in this category freed users from systems that could not accommodate variability in table schemas, that made clustered, geo-distributed infrastructure a major hassle, that employed different data representation paradigms than do most programming languages and which blocked operations while new data was written to the database.

But with these new freedoms, many RDBMS features that are so fundamental to most line-of-business systems were lost, going well beyond de-emphasis of the Structured Query Language (SQL) itself. Fundamental features that were sacrificed included indexes on columns other than the primary key, explicit joins between tables and so-called "ACID" guarantees -- where updates to one part of the database and compensating changes to other parts (like a credit, and a matching debit) happened indivisibly.

Rapprochement
The reconciliation of these database management architectures is finally in full swing. This week's announcement from MongoDB (the canonical document store NoSQL database) of its eponymous database's upcoming 3.4 release, along with the 3.1 beta release of graph database-in-chief Neo4j two weeks ago, are a big part of this. Other changes too, have been piling up, each one a peacenik's daisy in bringing an end to the database wars.
Also read: Couchbase NoSQL Database gets the SQL Religion
Also read: DataStax Enterprise 3.1: NoSQL; Yes, CQL.
Also read: Couchbase 2.0 released; implements JSON document store

Neo4j has softened the militant NoSQL approach of abandoning ACID guarantees and replacing it with NoSQL's darling, "eventual consistency." Instead, Neo4j 3.1 offers something it calls "Causal Consistency" (note: that's "causal," and not "casual"). This model makes operations more ACID-like, and allows developers to indicate the level of database consistency required when database reads take place very soon after writes.

Neo-retro
Eventually, all servers in a cluster will get the updates, and reads of the data affected will happen very quickly. But what about read requests of that data in the interim period? With version 3.1, Neo4j developers can specify whether that process must first finish in its entirety, or if the read can take place right away.

But, in the name of balance and nuance, developers can also allow the transaction to commit when the changes have replicated to a "quorum" of servers, one of which will answer the read request. Each option implies a different trade-off in performance and consistency. And that is how it should be, when requirements exist along a spectrum.

Ambi-Mongo
As covered in depth by Tony Baer earlier this week, MongoDB 3.4 is no longer just a document store -- in other words it goes beyond the storage and maintenance of JavaScript Object Notation (JSON)-encoded data entities. MongoDB now accommodates graph processing as well -- something which has been a separate NoSQL category. It's also added facet-based search technology. Akin to the approach taken by Internet and corporate search engines, faceted navigation allows data to be searched or filtered on dimensional values, a paradigm familiar to users of OLAP BI technology.
Also read: MongoDB 3.4 fills some enterprise database gaps

And if that weren't kumbaya enough for you, MongoDB 3.4 will, most ceremoniously, support a SQL query interface. This, in turn, will allow virtually all major BI packages to connect to MongoDB as a data source without needing special drivers, especially since MongoDB's SQL dialect will apparently be compatible with that of open source RDBMS MySQL.
Also read: Pentaho adds native integration with MongoDB

Redmond-inspired?
What's especially interesting about these changes is that they follow almost identical architectural compromises from Microsoft, an RDBMS incumbent. Despite its SQL Server heritage, some time ago Microsoft introduced a cloud-based NoSQL database of its own, called DocumentDB. As the name would suggest, the product is a document store NoSQL database.

Be that as it may, Microsoft imbued DocumentDB, at launch, with two category-bending features (that may now sound familiar): a SQL query interface, and configurable database consistency levels. More recently, Microsoft added a MongoDB API-compatible interface, which means both products now offer both query models. And with MongoDB's additional announcement of its Atlas cloud service, the two platforms are really going head-to-head.

If that's not good enough for you, consider that the newest version of SQL Server, Microsoft's nearly 25 year-old RDBMS product, now accommodates storage and search of data in the same JSON format as is native to DocumentDB and MongoDB. That doesn't mean "MS SQL" (as SQL Server is often referred to in non-Microsoft developer circles) is now NoSQL. What it does mean is that distinctions in the categories are blurring. They're also increasingly becoming misnomers.

It takes an industry
That's a good thing. Because, eventually, for the industry to advance, it must stop the infighting and move forward in a coordinated fashion.

Domination by one ideology is not good, and opposing approaches may need to organize and launch earnest campaigns for change. But, in the end, each side can learn from the other, forming a more enlightened, more inclusive, less adversarial landscape. Customers benefit, and so do vendors, freeing both to move on and solve new problems.