We are in the middle of one of our periodic analyst tours at MarkLogic, where we meet about 50 top software industry analysts focused in areas like enterprise search, enterprise content management, and database management systems. The NoSQL movement was one of four key topics we are covering, and while I’d expected some lively discussions about it, most of the time we have found ourselves educating people about NoSQL.
In this post, I’ll share the six key points we’re making about NoSQL on the tour.
Our first point is that NoSQL systems come in many flavors and it’s not just about key/value stores. These flavors include:
Key/value stores (e.g., Hadoop)
Document databases (e.g., MarkLogic, CouchDB)
Graph databases (e.g., AllegroGraph)
Distributed caching systems (e.g., Memcached)
Our second point is that NoSQL is part of a broader trend in database systems: specialization. The jack-of-all-trades relational database (e.g., Oracle, DB2) works reasonably well for a broad range of applications — but it is a master of none. For any specific application, you can design a specialized DBMS that will outperform Oracle by 10 to 1000 times. Specialization represents, in aggregate, the biggest threat to the big-three DBMS oligopolists. Examples of specialized DBMSs include:
Streambase, Skyler: real-time stream processing
MarkLogic: semi-structured data
Vertica, Greenplum: mid-range data warehousing
Aster: large-scale (aka “big data”) analytic data warehousing
VoltDB: high volume transaction processing
MATLAB: scientific data management
Our third point is that NoSQL is largely orthogonal to specialization. There are specialized NoSQL databases (e.g., MarkLogic) and there are specialized SQL databases (e.g., Aster, Volt). The only case where I think there are zero examples is general-purpose NoSQL systems. While I’m sure many of the NoSQL crowd would argue that their systems can do everything, is anyone *really* going to run general ledger or opportunity management on Hadoop? I don’t think so.
Our fourth point is that NoSQL isn’t about open source. The software-wants-to-be-free crowd wants to build open source into the definition of NoSQL and I believe that is both incorrect and a mistake. It’s incorrect because systems like MarkLogic (which uses an XML data model and XQuery) are indisputably NoSQL. And it’s a mistake because technology movements should be about technology, not business models. (The open source NoSQL gang can solve its problem simply by affiliating with both the NoSQL technology movement and the open source business model movements.)
As CEO of a company that’s invested a lot of energy in supporting standards, our fifth point was that, rather ironically, most open source NoSQL systems have proprietary interfaces. People shouldn’t confuse “can access the source code” with “can write applications that call standard interfaces” and ergo can swap components easily. If you take offense at the word proprietary, that’s fine. You can call them unique instead. But the point is an application written on Cassandra is not practically moved to Couch, regardless of whether you can access the source code both Couch and Cassandra.
Our sixth point is that we think MarkLogic provides a best-of-both-worlds option between open source NoSQL systems and traditional DBMSs. Like open source NoSQL systems, MarkLogic provides shared-nothing clustering on inexpensive hardware, superior support for unstructured data, document-orientation, and high-performance. But like traditional databases, MarkLogic speaks a high-level query language, implements industry standards, and is commercial-grade, supported software. This means that customers can scale applications on inexpensive computers and storage, avoid the pains of normalization and joins, have systems that run fast, can be implemented by normal database programmers, and feel safe that their applications are built via a standard query language (XQuery) that is supported by scores of vendors.
The other day I noticed a taxonomy used on one of the NoSQL Database blogs that went like this:
Types of NoSQL systems
Core NoSQL Systems
Wide column stores
Key-value / tuple stores
Eventually consistent key-value stores
Soft NoSQL Systems (not the original intention …)
Grid database solutions
Other NoSQL-related databases
I, perhaps obviously, take some umbrage at having MarkLogic (acceptably classified as an XML database) being declared “soft NoSQL.” In this post I’ll explain why.
Who decided that being open source was a requirement to be real NoSQL system? More importantly, who gets to decide? NoSQL – like the Tea Party – is a grass-roots, effectively leaderless movement towards relational database alternatives. Anyone arguing original intent of the founders is misguided because there is no small group of clearly identified founders to ask. In reality, all you can correctly argue is what you think was the intent of the initial NoSQL developers and early adopters, or — perhaps more customarily — why you were drawn to them yourself, disguised or confused as original founder intent.
As mentioned here, movements often appear homogeneous when they are indeed heterogeneous. What looks like a long line of demonstrators protesting a single cause is in fact a rugby scrum of different groups pushing in only generally aligned directions. For example, for each of the following potential motivations, I am certain that I can find some set of NoSQL advocates that are motivated by it:
A desire to land at a different point in the Brewer CAP Theorem triangle of consistency, availability, and partition tolerance
Coolness / wannabe-ism, as in, I want to be like Google or Facebook
(Since this was a source of confusion in prior posts, note that this is not to claim the inverse: that all NoSQL advocates are motivated by all of the possible motivations.)
I’d like to advocate a simple idea: that NoSQL means NoSQL. That a NoSQL system is defined as:
A structured storage system that is not based on relational database technology and does not use SQL as its primary query language
In short, my proposed definition means that NoSQL (broadly) = NoSQL (literally) + NoRelational. In short: relational database alternatives. It does not mean:
NoDBMS. We should not take NoSQL to exclude systems we would traditionally define as DBMSs. For example, supporting ACID transactions or supporting a non-SQL query language (e.g., XQuery) should not be exclusion criteria for NoSQL.
NoCommercialSoftware. While many of the flagship NoSQL projects (e.g., Hadoop, CouchDB) are open source projects, that should be not a defining criterion. NoSQL should be a technological, not a delivery- or business-model, classification. Technology and delivery model are orthogonal dimensions. We should be able to speak of traditionally licensed, open source licensed, and cloud-hosted NoSQL systems if for no other reason than understanding the nuances of the various business/delivery models is a major task unto itself. Do you mean open source or open core? Is it open source or faux-pen source? Under which open source license? How should I think of a hosted subscription service that is a based on or a derivative of an open source project?
Recently, I’ve heard a piece of backpeddling that I’ve found rather irritating: that NoSQL was never intended to mean “no SQL,” it was actually intended to mean “not only SQL.” Frankly, this strikes me as hogwash: uh oh, I’m afraid that people are seeing us as disruptors and it’s probably easier to penetrate the enterprise as complementary, not competitive, so let’s turn what was a direct assault into a flanking attack.
To me, it’s simple: NoSQL means NoSQL. No SQL query language and no relational database management system. Yes, it’s disruptive and — by some measures — “crazy talk” but no, we shouldn’t hide because there are lots of perfectly valid (and now socially acceptable) reasons to want to differ from the relational status quo.
In effect, my definition of NoSQL is relational database alternative. Such options include both alternative databases (e.g., MarkLogic) and database alternatives (e.g., key/value stores). This, of course, then cuts at your definition of database management system where I (for now at least) still require the support of a query language and the option to have ACID transactions.
By the way, I understand the desire to exclude various bandwagon-jumpers from the NoSQL cause. Like most, I have no interest in including thrice-reborn object databases in the discussion, but if the cost of excluding them is excluding systems like MarkLogic then I think that cost is too high. Many people contemplating the top-of-mind NoSQL systems (e.g., Hadoop) could be better served using MarkLogic which addresses many typical NoSQL concerns, including:
Highly parallel shared-nothing clusters
Support for unstructured and semi-structured data
All with all the pros (and cons) of being a commercial software package and without requiring reduced consistency: losing a few Tweets won’t kill Twitter, but losing a few articles, records, or individuals might well kill a patient, bank, or counter-terrorism agency. BASE is fine for some; many others still need ACID. Michael Stonebraker has some further points on this idea in this CACM post.
I’d like to suggest that we should combine the ideas in this post with the ideas in my prior one, Classifying Database Management Systems. That post says the correct way to classify DBMSs is by their native modeling element (e.g., table, class, hypercube). This post says that NoSQL is semi-orthogonal – i.e., I can imagine a table-oriented database that doesn’t use SQL as its query language, but I doubt that any exist. Applying my various rules, the combined posts say that:
Aster is a SQL database optimized for analytics on big data
MarkLogic is an XML [document] database optimized for large quantities of semi-structured information and a NoSQL system
Finally, I’d conclude that even with these rules I have trouble classifying MarkLogic because of multiple inheritance: MarkLogic is both a document database and an XML database, it is difficult to pick one over the other, and I there certainly are non-document-oriented XML database systems. Similar issues exist with classifying the various hybrids of document databases and key/value stores. So while I may have more work to do on building an overall taxonomy, I am absolutely sure about one thing: MarkLogic is a NoSQL system.
* The “Yes, Virginia” phrase comes from a 1897 story in the New York Sun. For more, see here.
Without a doubt, the most controversial post I’ve written on this blog was last month’s The Database Tea Party: The NoSQL Movement. I know this both from the comment stream, but also from the volume and tenor of emails I received from friends and colleagues over the past few weeks.
The first thing I learned is that standing in the middle is a great way to get attacked from all sides.
My database buddies blasted me, treating me like a reckless turncoat: how dare you endorse these BASE people? (Humorous double entendre intended.)
The NoSQL folks blasted me, generally misunderstanding the protest march metaphor I was using (see below).
The above-it-all crowd blasted me for oversimplifying the issue, suggesting that I was endorsing simplistic views such as it’s about batch vs. online or it’s about scaling vs. not scaling.
All of which, of course, only confirmed the religious nature of the movement and that was indeed a movement, regardless of whether any given participant identified himself as such.
(Several folks also blasted me for using the Tea Party Movement as a metaphor. Let me clarify that this is not a political blog so I won’t debate politics. I intended the metaphor to cover only concepts like “rebellion” and “grass roots,” both of which I do believe apply to NoSQL.)
First, I’ll clarify the protest march metaphor which was easily the most misunderstood aspect of the post. Let me share my first rule of protests: not everyone is there for the same reason. Some people are there for the stated cause, which I’ll call cause A. But others participate on behalf of a group; their signs will say “Group 1’s for Cause A.” Others are there for cause B which lacks enough support to generate its own march, so they tag along with signs saying “Cause A and Cause B.” If you’ve ever been at a rally, you’ve invariably winced when speakers attempted to hijack the agenda, turning to some personal cause, all while pretending to speak on behalf of the group.
It was this sense of chaos and disorder that I was trying to portray. When I made the list of reasons why I thought people were on the NoSQL march, it was neither to say that I agreed with them or that all people were there for all reasons. I was doing the equivalent of asking protesters on the UC Berkeley Anti-Grenada March why they were there. To which the replies might have been:
To protest the Grenada invasion (cause A)
To remind people about [insert group here] rights, all while protesting against Grenada
To protest about UC budget cuts, all while protesting about something the Government did, which I’m pretty sure was bad.
Because I go to every march; what’s this one about?
Because I was at Top Dog when it went by and had nothing better to do
So hopefully, the intent of my NoSQL-reasons-list is now clear. Some folks are there because they don’t want ACID transactions. Some folks are there because they are dealing with Internet scale. Some folks are there because they hate the SQL impedance mismatch. Some folks are there because they’re tired of paying oligopoly prices to Oracle. (I particularly liked the comment that said Oracle was free because they had an enterprise license that most certainly wasn’t, ignoring the possibility that recent enterprise/agency directives to look at open source could result directly from the size of the last Oracle check.)
And yes, some folks are there because it’s cool and they want to be like Twitter, Google, and Facebook, but getting them to admit that is a virtual impossibility.
One irony is that I actually agree with one of the fiercest commenters:
A very interesting write-up with one little oversight: you’re wrong.
I am part of a large program to write a NoSQL database for military applications. [It’s not about …] It’s [about] the fact that RDBMSs are built in a different space in the CAP trades.
Google, Amazon, Facebook, and DARPA all recognized that when you scale systems large enough, you can never put enough iron in one place to get the job done (and you wouldn’t want to, to prevent a single point of failure). Once you accept that you have a distributed system, you need to give up consistency or availability, which the fundamental transactionality of traditional RDBMSs cannot abide. Based on the realization that something fundamentally different needed to be built, a lot of very smart people tackled the problem in a variety of different ways, making different trades along the way. […]
So – the NoSQL databases are a pragmatic response to growing scale of databases and the falling prices of commodity hardware. It’s not a noble counterculture movement (although it does attract the sort that have a great deal of mental flexibility), it’s just a way to get business done cheaper.
To respond to the commenter:
Thank you for the clear definition of why you moved to NoSQL.
Disorder and chaos is what I was trying to portray in the protest march metaphor, not hippies or nobility
You are clearly using NoSQL for two of the reasons on my list: scalability and bloatware (i.e., perhaps not the best word choice, but the idea was undesired, included functionality — e.g., ACID transactions)
You did exactly what I said to do: consider all alternatives and do what’s right for your business
So, why are we disagreeing again?
I think some people didn’t like my putting “coolness” on the table as a factor and the notion of a “movement.” I believe those are both very real and ironically those who disagreed with me loudest were effectively screaming: it’s not a movement and I’m not doing it to be cool; I’m doing it because it’s right for my business. If so, great. But why does it hit such a nerve?
In the end, when it comes to NoSQL I am trying to:
Provide an overview of why I think people are considering and/or using NoSQL solutions
Provide good background references and readings (see bottom of my first post)
Remind mangers to keep an eye out for the “bad reasons” to go NoSQL — i.e,. coolness and Google wannabeism
Remind people not to confuse NoSQL with NoDatabase. Special-purpose databases (e.g., MarkLogic) are optimized for specific applications (e.g., semi-structured data) and handle them far better than a general-purpose RDBMS. So in your haste to move off Oracle, don’t advance directly to an open source key-value store; there might be alternative DBMSs that meet your needs more effectively.
Remind people not to confuse NoSQL with NoCommercialSoftware. While people seem to dislike when I say it, the RDBMS market is an oligopoly and the big vendors’ pricing, margins, and heavy-handed customer relationships are all consistent with that market structure. But you can find other classes of commercial software where the vendors are hungrier and more customer centric.
If you have a bunch of XML and are looking for of a place to put it, then I think I may have come up with a simple test that might be helpful.
In talking with prospective vendors of XML repositories (definition: software that lets you store, search, analyze and deliver XML), try to establish what I’ll call “XML vision compatibility.” Quite simply, try to figure out if the vendor’s vision of XML is consistent with your own. To help with that exercise, I’ll define what I see as the three common XML vendor visions:
YAFF (yet another file format)
YADT (yet another data type)
Vendors with the YAFF vision view XML as yet another file format. ECM vendors clearly fall into this category (“oh yes, XML is one of the 137 file formats you can manage in our system”). So do enterprise search vendors (“oh yes, we have filters for XML formatted files which clear out all those nasty tags and feed our indexing engine the lovely text.”)
For example, let’s look at how EMC Documentum — one of the more XML-aggressive ECM vendors — handles XML on its website.
Hmm. There’s no XML on that page. But lots of information about records management, digital asset management, document capture, collaboration and document managent (it’s not there either). Gosh, I wonder where it is? SAP integration? Don’t think so. Hey, let’s try Documentum Platform, whatever that is.
Not there, either. Now that’s surprising because I really have no idea where else it might be. Oh, wait a minute. I didn’t scroll the page down. Let’s try that.
There we go. We finally found it. I knew they were committed to XML. What’s going on here is that EMC has a huge, largely vendor consolidation-driven (e.g., Documentum, Captiva, Document Sciences, x-Hive, Kazeon) vision of what content management is. And XML is just one tiny piece of that vision. XML is, well, yet another file format among the scores that they have manage, archive, capture, and provide workflow, compliance, and process management against. The vision isn’t about XML. It’s about content. That’s nice if you have an ECM problem (and a lot of money to solve it); t’s not so nice if you have an XML problem, or more precisely a problem that can be solved with XML.
Vendors with the YADT vision view XML as yet another data type. These are the relational database management system vendors (e.g., Oracle) who have decided that the best way to handle XML is to make it a valid datatype for a column in a table.
The roots of this approach go back to the late 1980s and Ingres 6.3 (see this semi-related blast from the past) which was the first commercial DBMS to provide support for user-defined datatypes. All the primitives for datatyping were isolated from the core server code and made extensible through standard APIs. So, for example, if you wanted to store complex numbers of the form (a, bi) all you had to do was to write some primitives so the server would know:
What they look like — i.e., (a, bi)
Any range constraints (the biggest, the smallest)
What operators should be available (e.g., +, -)
How to implement those operators — (a, bi) + (c, di) = (a+c, (b+d)i)
It was — far as I remember — yet another clever idea from the biggest visionary in database management systems after Codd himself: Michael Stonebraker then of UC Berkeley and now of MIT. After founding Ingres, Stonebraker went on found Illustra which was all about “datablades” — a sexy new name for user-defined types. Datablades, in turn, became sexy bait for Informix to buy the company with an eye towards leveraging the technology towards unseating Oracle from its leadership position. It didn’t happen.
User-defined datatypes basically didn’t work. There were two key problems:
You had user-written code running in the same address space as the database server. This made it nearly impossible to determine fault when the server crashed. Was it a database server bug, or did the customer cause problem in implementing a UDT? While RDBMS customers were well qualified to write applications and SQL, writing server-level was quite another affair. This was a bad idea.
Indexing and query processing performance. It’s fairly simple to say that, for example, a text field looks like a string of words and the + operator means concatenate. It’s basically impossible for a end customer to tell the query optimizer how to process queries involving those text fields and how to build indexes that maximize query performance. If getting stuff into UDTs was a level-5 challenge, getting stuff back out quickly was a level-100 one.
So while the notion of end users adding types to a DBMS basically failed, when XML came along the database vendors dusted off this approach, in saying effectively: let use all those hooks we put in to build support for XML types ourselves. And they did. Hence what I call the “XML column” approach to storing XML in a relational database.
After all, if your only data modeling element’s a table, then every problem looks like a column.
Now this approach isn’t necessarily bad. If, for example, you have a bunch of resumes and want to store attribute data in columns (e.g., name, address, phone, birthdate) and keep an XML copy of the resume alongside, then this might be a reasonable way to do things. That is, if you have a lot of data and a touch of XML, this may be the right way to do things.
So again, it comes down to vision alignment. If XML is just another type of data that you want to store in a column, then this might work for you. Bear in mind you’ll:
Probably have to setup separate text and pre-defined XML path indexes (a hassle on regular schemas, an impossibility on irregular ones),
Face some limitations in how those indexes can be combined and optimized in processing queries,
Need to construct frankenqueries that mix SQL and XQuery, whose mixed-language semantics are sometimes so obscure that I’ve seen experts argue for hours about what the “correct” answer for a given queries is,
And suffer from potentially crippling performance problems as you scale to large amounts of XML.
But if those aren’t problems, then this approach might work for you.
This is what it looks like when a vendor has a YADT vision. Half the fun in storing XML in an RDBMS is figure out which query language and which store options you want to use. See the table that starts on page 9, spans four pages, and considers nearly a dozen criteria to help you decide which of the three primary storage options you should use:
See this post from IBM for more Oracle-poking on the complexity of storage options available. Excerpt:
Oracle has long claimed that the fact that Oracle Database has multiple different ways to store XML data is an advantage. At last count, I think they have something like seven different options:
XML-Object-Relational, where you store repeating elements in CLOBs
XML-Object-Relational, where you store repeating elements in VARRAY as LOBs
XML-Object-Relational, where you store repeating elements in VARRAY as nested tables
XML-Object-Relational, where you store repeating elements in VARRAY as XMLType pointers to BLOBs
XML-Object-Relational, where you store repeating elements in VARRAY as XMLType pointers to nested tables
Their argument is that XML has diverse use cases and you need different storage methods to handle those diverse use cases. I don’t know about you, but I find this list to be a little bewildering. How do you decide among the options? And what happens if you change your mind and want to change storage method?
Such is life in the land of putting XML in tables because your database management system has columns.
Whole World Vendors
Vendors with the whole world vision view XML as, well, their whole world.
And when I say XML, I don’t mean information that’s already in XML. I mean information that is either already in XML (e.g., documents, information in any horizontal or industry-specific XML standard) or that is best modeled in XML (e.g., sparse data, irregular information, semi-structured information, information in no, multiple, and/or time-varying schemas).
Whole world vendors don’t view XML tags as “something that get in the way of the text” and thus they don’t provide filters for XML files. Nor do they require schema adherence because they know that XML schema compliance, in real life, tends to be more of an aspiration than a reality. So they allow you load and index XML, as is, avoiding the first step’s a doozy problem, and enabling lazy clean-up of XML information.
Whole world vendors don’t try to model XML in tables simple because they have a legacy tabular data model. Instead, their native modeling element (NME) is the XML document. That is:
In a hierarchical DBMS the NME is the hierarchy
In a network DBMS the NME is the graph
In a relational DBMS the NME is the table
In an object DBMS the NME is the object class hierarchy
In an OLAP, or multi-dimensional, DBMS the NME is the hypercube
And in an XML server, or native XML, DBMS the NME is the XML document
Whole world vendors don’t bolt a search engine to a DBMS because they know XML is often document-centric, making search an integral function, and requiring a fundamentally hybrid search/database — as opposed to a bolted-together search/database — approach.
Here is what it looks like when you encounter a whole world vendor:
It’s no secret that I’m not a big fan of “magic” in software. You could argue I’m still bearing the scars from BusinessMiner, one of our few failed products, at Business Objects. You could argue that for some tasks, magic is a necessary evil, and I wouldn’t argue back too hard. Many Mark Logic customers rely on “magic” to automatically enrich content, adding XML tags that identify entities (e.g., people, places, geopolitical organizations), sentiment (e.g., positive, negative or neutral), or even geo-code content with latitude and longitude that we then index, thus enabling geo-queries against content.
While I confess to some ignorance about how the magical tools work, it’s my perception that on a bad day they’re 50% accurate and on a good one they’re 80%. Now one could argue that content that’s enriched at 80% accuracy is way more valuable than unenriched content, and you’d be right. All I’m saying is I’m glad I’m not in the business of making the software that does that, because — customers being customers — nobody wants to hear that 80% is great and 100% is unattainable. Perhaps it’s my lack of deep expertise in the field. Or perhaps it’s my belief that humans are uncomfortable around black boxes.
The other reason I don’t like magic is that it can fail in truly spectacular ways. What’s the expression? To err is human. To really foul things up requires natural language processing.
Several of our readers tested out the site and found that healthBase’s semantic search engine has some major glitches (see the comments). One of the most unfortunate examples is when you type in a search for “AIDS,” one of the listed causes of the disease is “Jew.” Really.
The ridiculousness continues. When you click on Jew, you can see proper “Treatments” for Jews, “Drugs And Medications” for Jews and “Complications” for Jews. Apparently, “alcohol” and “coarse salt” are treatments to get rid of Jews, as is Dr. Pepper! Who knew?
Here’s a great demo of why I don’t want to sell semantic processing technology. Here’s the reply Netbase gave TechCrunch:
This is an unfortunate example of homonymy, i.e., words that have different meanings.
The showcase was not configured to distinguish between the disease “AIDS” and the verb “aids” (as in aiding someone). If you click on the result “Jew” you see a sentence from a Wikipedia page about 7th Century history: “Hispano-Visigothic king Egica accuses the Jews of aiding the Muslims, and sentences all Jews to slavery. ” Although Wikipedia contains a lot of great health information it also contains non-health related information (like this one) that is hard to filter out.
I hate to be pedestrian, but isn’t that just a fancy way of saying it doesn’t work? It reminds me of the quip about Autonomy, where, when the Bayesian and Shanon’s Information Theory magic isn’t working, they simply tell the customer that they’re not smart enough to understand why. Nice.
Now, for the hapless NetBase, the AIDS query was just the beginning. They get destroyed in the blog comments, which quickly turned into a contest to find the silliest results.
The treatment for venture capital is funding. The cons is fool.
Masturbation causes insanity and is cured by cocaine.
The treatment for Twitter is Facebook. (This one might be right.)
The treatment for Microsoft is Viagra
Babies are caused by smoking and brain damage
It goes on and on. Now yes, many of the silly queries are out of the health domain, but there has to be better way to answer them.
One active commenter, Dave, who coined the “tragicomedy” description and who isn’t me, had this to offer:
The tragi-comic failure of Netbase can teach a lot to every company in the Semantic space.
Don’t even try to boil the ocean of the WWW with these technologies. [The] Internet is full of valuable information but crap (or opinions) is 90% [of it] , the cost of getting rid of this crap and save only the good stuff is very high, [and] that’s [what] makes [it] so hard to succed even for Google and Microsoft with billions [of dollars].
Linguistic approaches are likely going to fail because search engines (and machines) can’t distinguish joke/seriousness, sarcasm/shame and sentiments in general. The semantic meaning is right there not in the words of a text.
If you choose to apply such approaches to one specific topic like Medicine (good choice) then stick to that topic , that means accept as INPUT only medical terms and provide as OUTPUTS only medical terms.
This last point requires human intervention and predefined taxonomies/ontologies but Netbase claims that they don’t need them both, ]i.e., that] their engine is fully automatic —> the failure too.
I’m Dave Kellogg, advisor, director, consultant, angel investor, and blogger focused on enterprise software startups. I am an executive-in-residence (EIR) at Balderton Capital and principal of my own eponymous consulting business.
I bring an uncommon perspective to startup challenges having 10 years’ experience at each of the CEO, CMO, and independent director levels across 10+ companies ranging in size from zero to over $1B in revenues.
From 2012 to 2018, I was CEO of cloud EPM vendor Host Analytics, where we quintupled ARR while halving customer acquisition costs in a competitive market, ultimately selling the company in a private equity transaction.
Previously, I was SVP/GM of the $500M Service Cloud business at Salesforce; CEO of NoSQL database provider MarkLogic, which we grew from zero to $80M over 6 years; and CMO at Business Objects for nearly a decade as we grew from $30M to over $1B in revenues. I started my career in technical and product marketing positions at Ingres and Versant.
I love disruption, startups, and Silicon Valley and have had the pleasure of working in varied capacities with companies including Bluecore, Cyral, FloQast, GainSight, MongoDB, Recorded Future, and Tableau.
I previously sat on the boards of Granular (agtech, acquired by DuPont), Aster Data (big data, acquired by Teradata), and Nuxeo (content services, acquired by Hyland), and Profisee (MDM, exited to Pamlico).
I periodically speak to strategy and entrepreneurship classes at the Haas School of Business (UC Berkeley) and Hautes Études Commerciales de Paris (HEC).