Long synonymous with relational databases, Oracle wants to tell developers that it’s not only for SQL programmers or priced just for enterprises. And so, it’s announcing a new JSON-only document database service on the Oracle Cloud on its most accessible platform – the Autonomous Database – to appeal to developers looking at JSON as their default. And it is pricing it very aggressively.
It’s all accessed via Oracle’s own SODA API (Simple Oracle Document Access), which it claims is similar to MongoDB, and can be implemented through the languages listed above. We were shown some coding examples comparing SODA to MongoDB query language and found that the languages were structured similarly, but still had their differences.
Oracle is taking several steps to make the Autonomous JSON Database attractive to developers.
First of all, it’s autonomous. That means that, atop database automation capabilities such as with resource or memory management (Oracle has well over a dozen capabilities it’s built over the years), the Autonomous Database applies machine learning to make decisions on how to run the system. It relieves developers of most operational, but not strategic decisions like how to model, deploy, and query the data. With an autonomous database, developers can focus on modeling the data and designing the application and not worry about the operations side.
Oracle has several versions of the Autonomous Database, which it began introducing a couple years ago. The JSON edition is based on Oracle Autonomous Transaction Processing Database. It’s offered as a serverless platform under the enterprise service level that delivers four nines 99.995%) of availability.
The going notion of the Autonomous JSON Database is that, after a relatively simple sign-up page, the developer specifies the processing power (in terms of OCPUs), the total amount of storage (in terms of TBytes) and an Admin user password; like most cloud-managed Database-as-a-Service (DBaaS) offerings, the Autonomous JSON Database then auto-provisions and deploys. The difference with the Oracle Autonomous Database starts right after the deployment; no DBA is required to operate or manage the Autonomous JSON Database. Instead, the database takes care of these mundane functions with self-healing, software patching, automatic updates and uses machine learning to optimize query planning and self-tune itself. The developer still has the choice to manually create application indexes, if desired.
Autonomous JSON Database also supports elasticity. OCPUs and TBytes can be scaled up and down independently without any outage to the application. With the auto-scaling option enabled, the database will also scale the amount of OCPUs by itself based on the workload requirements. The same goes with storage; JSON developers will never need to worry if they have enough storage available again.
Secondly, Oracle is pricing the JSON edition for less than the cost of the full Oracle Autonomous Database, with costs pegged at similar levels as Amazon DocumentDB. They go as low as $2.74/hour for 8 OCPUs and 1 TByte of storage. Oracle claims that it also underprices MongoDB Atlas, but as Atlas publishes a different pricing model, it’s difficult to make direct apples-to-apples comparisons. Oracle also offers a free cloud tier so developers can use Oracle Autonomous JSON Database to build, test, and deploy applications on Oracle Cloud Infrastructure.
Having chosen the JSON edition, customers are not locked in there, as Oracle is more than happy to make it easy to get them to upgrade to the full, relational multimodel database. Developers can do so with a single click.
Multimodel is part of a general shift on Oracle’s part, first to broaden the positioning of the Oracle Database to what it terms a “converged’ database (in plain English that means multi-model). Beyond relational, the full Oracle Database supports JSON, graph, spatial, key-value data, and others.
Having JSON support in a relational database is not new – it’s been pretty common since IBM started adding JSON support to Db2 back in 2013. Originally, most relational platforms supported JSON in flattened form, where the richness of JSON nested documents were often compressed into a single column. But in recent years, support of JSON in mainstream relational platforms has become much richer. For instance, while Oracle initially supported JSON as variable character strings (which originated from its longtime support of XML), in recent years the support has become more native.
As for multi-model, that’s also being embraced by most of the (relational) usual suspects. For instance, SAP is promoting HANA’s multi-model capabilities, and so is Teradata with its data warehouse. For Oracle, and most of its rivals, it’s all about painting a contrast with AWS, and to a lesser extent, Google, whose portfolios are predominantly fit-for-purpose databases. The debate over multi-model vs. fit-for-purpose is a larger discussion, but suffice it to say that Oracle claims an advantage of its multimodel approach is that security profiles, high-availability support, and management frameworks are all under the same umbrella compared to running multiple separate databases.
The bottom line, however, is all about autonomous services. That’s what differentiates the JSON service from other cloud document databases. And that is how Oracle is differentiating, not only its database, but also its cloud infrastructure services in general, with other autonomous services such as Autonomous Data Guard and Autonomous Linux. But, arguably, with databases where Oracle controls more of the moving parts, they are the key showcase for demonstrating the capabilities of autonomous services. The data-intensive nature of database operations – there is scads of log data – makes it ideal for applying ML.
Increasingly, other databases are incorporating ML, mostly as aids for guiding DBAs on how to model data, develop query plans, or generate indexes. But few of them have the underlying automation to take the human out of the equation for functions ranging from storage and memory management to diagnostic monitors, query rewrite, workload replay, scaling, patching, and so on.
Bringing the autonomous database to JSON at a low price point is a good start for Oracle. Nobody else offers autonomous database services, JSON or not. But to go beyond its own installed base to meet JSON document database developers where they live, Oracle needs to go the last mile and add support for the MongoDB APIs that remain publicly available to third parties. IBM, Microsoft, AWS, Percona and others already run cloud services that are compatible with the old MongoDB API – there’s no reason that Oracle, with the unique advantage of its autonomous database, can’t do the same.