Why we invested in a startup building an entirely new database
By: Guy Yamen
Tags: Database, VC, Rdbms, Investment, NoSQL

A few months ago, we’d made an initial investment in Paramount Data (PD; temporary name — stay tuned!). Here are a few words on why we did.

We at TPY are fascinated by data. This draws our team to startups that generate data which did not exist before, or those which synthesize various types of data and make it available to generate actionable insights.

We also look at the usage of data to streamline and digitize organizational processes. And while it is undoubtedly less ’sexy’ at first sight, we do explore opportunities all the way down at the bottom of the data stack — where, among other peculiar creatures — PD resides.

At a high level, PD pertains to do something very tough: develop a whole new database. And developing a new database means exactly that: not an extension of an existing database, not a minor modification to an existing database, but a new database altogether.

Given this audacious task, we had to believe two things as an investment team:

a. that the existing solutions are not solving for what is a real and substantial pain

b. that this specific team can offer a viable solution to this pain

Addressing a real, and BIG, pain point

One can slice and dice the world of databases in many ways. A common one is the distinction between Relational databases and NoSQL ones;

Relational Database Management Systems (RDBMSs) support transaction consistency (ACID) and high performance but cannot represent various types of data and have limited scalability capabilities. Also known as SQL databases, RDBMS cannot run OLTP (transactional) and OLAP (analytics) in parallel because it would affect the database.

Oracle, MySQL, and Microsoft SQL are all part of this family of databases.

NoSQL databases provide more elasticity than relational databases. They are based on one of several data models supporting semi-structured or unstructured types of data, and at larger volumes. They do so not at the single database entity level, but rather on a cluster of servers, each acting as an independent sub-database.

Similar to their relational cousins, NoSQL databases are not very friendly to analytics heavy load. In addition, they have multiple architectural flaws, including lack of transaction consistency or ability to perform query operations across the sub-database servers’ boundaries. Both are crucial elements for enterprise-grade data infrastructures.

Among members of this group are MongoDB, Cassandra, and Couchbase.

See below a rough comparison of the two types of databases:

TPY analysis

Then you have the newcomers or next-gen databases offering modern architecture databases This subset of offerings is known as NewSQL. The basic idea is to combine consistency (ACID) which RDBMS provides with the scalability and elasticity of NoSQL. We believe most NewSQL companies are still searching their way to delivering this promise, given that they were mostly built on top of existing (RDBMS or NoSQL) architecture.

Among the most popular NewSQL companies are Google Spanner, MariaDB’s Clustrix, and Cockroach Labs, and YugabyteDB (which are inspired by Google Spanner’s 2012 whitepaper).

So when we look at current day database deployment at the enterprise level, both RDBMS and NoSQL databases are typically being used in order to handle the unique limitations each of them imposes and given the clear tradeoff between the two.

And so, to support existing enterprise infrastructure with multiple types of data, developers are forced to deploy multiple “siloed” databases and use a mix of RDBMS and NoSQL.

As a result, it is impossible to get reports or run real-time analytics on data across siloed databases’, unless that data is duplicated into a data warehouse or a data lake. Such data duplication (sometimes called ETL) is operationally expensive and labor-intensive. When the enterprise needs to perform and support real-time data analytics, the inherent delay involved with ETL deems data lakes or data warehouses irrelevant.

===

Enter PD, who is building a large-scale database that contains the best elements of both the relational and NoSQL databases and online analytics.

We believe PD had already solved several technology challenges at the core of this industry, by developing a highly scalable, enterprise-grade, high performance, elastic database that offers:

Grow & shrink the database cluster elastically, ubiquitously to the user or application

Distributed ACID while maintaining high performance

Distributed compute (e.g. distributed JOIN)

Co-existence of OLTP and OLAP

Unified rich data model

In a nutshell, PD’s software-only database brings together the benefits of relational databases, NoSQL databases, and data analytics/lakes/warehouses in a single cluster.

The initial sectors PD is tackling are financial services, government, web application enterprises, and pharmaceuticals. As the world is becoming more real-time, organizations are interested in faster application-time-to-market, higher performance applications, and more real-time insights into both hot and historical data.

As most industries today use large amounts of historical data they are willing to pay for solutions that can fundamentally improve their data architecture, simplify development, significantly expedite/shorten application-time-to-market, and enable unprecedented analytics capabilities and time-to-data-insights.

Team. Team. Team.

We’d met two of the three co-founders at a bar.

No, this is not the start of a joke but the surprising reality that good things can actually come out VC industry events!

What had struck us — beyond realizing that these two can carry their drinks — were a few elements which became only more obvious as we got to know the team better in the following months:

a. The founders had worked together in past startups, including the latest one, ScaleIO which they’d sold to EMC a few years back. It maybe goes without saying, but there’s something very compelling

b. The founding team started working on PD January 2019, alongside five other team members, who had joined in the summer of 2019, and all have been working on both design and coding, with product development progressing according to plan. Our estimate is that no less than 55 months of cumulative work had been put into venture prior to the initial investment.

c. We loved the fact that from day one the team was seeking to identify commercial applications, rather than building the startup at the darkness of stealth, waiting for the design partnership to unveil itself after years of development.

d. As we got to know each other better, we were impressed by the team’s hard-working attitude; the practicality they showed in the negotiations with us; and the down to earth culture.

And when we say down to earth we mean it — PD is based out of a small village about an hour north of Tel Aviv, just next to a cowshed!

TPY is excited to partner with Boaz Palgi, Erez Webman, Eran Borovik, and the rest of the PD team in the journey to offer a whole new breed of a database.