9 ms·

Neo4j raises $325M series F

154 points by hugofirth 5y ago

mkr-hn 5y ago
It's always interesting to hear about huge funding rounds for companies I've never heard of. Even more so when they apparently work with a bunch of companies I have heard of.
- handrous 5y ago
  They're a fairly major graph database product with a well-funded sales team that has been hammering the "I mean, doesn't everything look kinda like a graph? Isn't your data kinda a graph? You should definitely use us as your database-of-record, or for literally anything else you might use a database for, look how fast we are at graph stuff!" line hard and (apparently) with great success.
  - objektif 5y ago
    So are you saying sales works?
    - handrous 5y ago
      Yeah, I mean, it's not the first time a database that's best-suited to a niche use-case has successfully had its market hugely expanded by sales & marketing promoting it as a superior replacement for what are in fact better general-use products. Clearly, it's a playbook that works.
  - dgb23 5y ago
    I’ve used it in production roughly 5+ years ago. Both graph data modeling and cypher queries are very fun to work with. It’s both dynamic and powerful but still gives you a decent amount of structure and ACID guarantees. One thing that is much easier to model and query, or rather more natural and simple, is authorization and other granular questions you might have about how users and data is connected. A thing that I can’t wrap my head around however is temporal data modeling with graphs. Haven’t seen or thought of anything too satisfying yet, that meshes well with how I think about graphs. Whereas in SQL it is more explored and clear to me. I agree that their marketing is very aggressive, but this tech has quite some merit.
    - LukeEF 5y ago
      check OpenCrux and TerminusDB - both time traveling graphs which specialize in temporal data modelling
  - oauea 5y ago
    I'm sure it's fast, but also consumes a ridiculous amount of memory. Tried loading a smallish dataset into neo4j that runs on a 100mb ram postgres server just fine. Neo4j wanted gigabytes of memory.
    - economusty 5y ago
      Gotta love the jvm.
    - handrous 5y ago
      When I used it, it was fast at a very specific set of graph traversal operations. It was extremely easy to step outside those narrow patterns, while doing things that seemed like they should be fine and were very common sorts of things one might want to do with the DB, at which point performance would become terrible. A look at the underlying data structures they use was revealing re: why they were so fast at some things, and so slow at others. And they only achieved that much performance by, as you note, eating memory like it's free (I mean, it is Java...). It was also alarmingly weak on data-integrity protection features, like constraints, locking, and data-types, at the time. IDK, maybe they've fixed that. Then, it was IMO wholly unsuited to hosting any data set that you couldn't stand to have completely destroyed every so often (so, a very particular kind of caching, which IIRC is exactly what one of their marketing department's favorite names to trot out, Ebay, used it for then). [EDIT] I would, however, agree with nisa's post elsewhere in the thread, that the Cypher query language is excellent.
      - nisa 5y ago
        only looked through papers but this didn't look good for them (but maybe an older version - paper is from 2015): https://static.googleusercontent.com/media/research.google.com/de//pubs/archive/43287.pdf https://static.googleusercontent.com/media/research.google.c... - that's why apache age is really interesting or will be maybe one day.
    - deleted 5y ago
      [deleted]
    - detaro 5y ago
  - chippiewill 5y ago
    I used to work for a database vendor. I'm getting serious 'nam style flashbacks reading your comment. The capability of sales to sell a product to massive companies for a use case that we're actually not very good at was unbelievable.
    - handrous 5y ago
      It keeps working, so I can't hardly blame companies for doing it. The people who are falling for it, on the other hand....
    - cerved 5y ago
      I used to work in IT sales and I'm not surprised
whalesalad 5y ago
> Series F Yikes > largest investment in a private database company I guess this is one of those PR moves that is trying to make something lame sound good? If your customer portfolio includes Walmart, Volvo and AstraZeneca why are you raising money a 6th time?
- caturopath 5y ago
  Having some department at e.g. Volvo using your product doesn't mean that you have Volvo as a serious customer paying you like they would as a serious customer. I take your point that this is a really late round of funding, but this doesn't mean they've caught on like they want to yet.
  - whalesalad 5y ago
    I agree that what you've described is likely the true situation. It just looks funny to see a company claim to be worth $2 billion dollars and namedrop big brands and yet require a 6th cash injection. There is an incongruence there.
    - latenightcoding 5y ago
      But that's how most big tech companies have been operating for the last 10-15(?) years. How do you think public companies that have never made a $ got there.
      - dalbasal 5y ago
        True. Private funding rounds this big just weren't available, so these were IPOs instead of round FS.
    - dvirsky 5y ago
      Redis Labs are more or less doing the same.
- httpz 5y ago
  Series F by itself isn't necessarily a bad thing anymore. Uber, Lyft, Airbnb, Snowflake all had Series F rounds at one point.
haolez 5y ago
Series F? Is that a bad smell or is it considered normal nowadays? Genuine question.
- hacksaw_hetty 5y ago
  Normal - just take a look on crunchbase
- not_jd_salinger 5y ago
  Both. I personally find the fact that having these later and later rounds of funding considered normal a huge indicator that something is very wrong with the current industry. It means there's a lot of capital being dumped into trying to find some hidden source of profit and it's getting harder and harder to find it. It's the capital equivalent of going from finding oil in your back yard to blasting it out of tar sands in the Canadian tundra. Sure the capital/oil keeps flowing, but the inherent unsustainability of the system starts to show its face more clearly.
- phillipcarter 5y ago
  Another way I look at this is that wealth has accumulated so disproportionately at the top that the small number of individuals/firms flush with wealth need to find ways to spend the money. So why not dump hundreds of millions on another company? Since there isn't any actual force coming in to take and redistribute it, might as well spend it.
- dcolkitt 5y ago
  Ever since Sarbanes-Oxley there's been a continuously declining number of new public companies. The reality is the modern legal and regulatory environment makes being a public company significantly more burdensome than it was in 1995. There's more than abundant amounts of capital in private equity, so the only real reason to go public is to create liquidity for early founders/investors/employees who want to cash out. Given that, arguably you could say going public, instead of raising private capital, is the smell. Or at least an attempt to top-tick the valuation, e.g. WeWork.
nisa 5y ago
cypher is really cool and with neosemantics[1] you have the best of both worlds - labeled property graphs and rdf* they even have a cool reasoner and sparql. that being said I thought about porting it to postgresql with apache age vs. using neo4j for a project because it's faster at least for this usecase. Easier said than done, through. If you want to play with graphs and linked-data it's super cool. There is also structr[2] that builds CMIS / Alfresco ECM like functionality atop neo4j with graaljs scripts. 1: https://github.com/neo4j-labs/neosemantics https://github.com/neo4j-labs/neosemantics 2: https://github.com/structr/structr https://github.com/structr/structr
Grimm1 5y ago
What this tells me is that the graph db space has a lot of room in it for someone to come along and make a kick ass product, because honestly every time I've had a problem a graph db can solve I remember I basically only have a few mediocre choices to choose from. Neo4J has been very meh in my experience, but they are the biggest.
- The_rationalist 5y ago
  What make you consider Tinkerpop mediocre?
  - Grimm1 5y ago
    Honestly I never heard of it, I had a few in mind but that wasn't one. I'll give it a try next time I need a graph db maybe it can scratch my itch so to speak. My concerns basically range around memory consumption, query language and language ecosystem. Edit: Oh and I guess around like functional extensibility. The last time I used a graph DB I had to export from the db itself to HDFS and use Spark to do things like PageRank and I'd rather be able to write that natively in their query lang or some like UDF equivalent.
    - jexp 5y ago
      That's what you can do in Neo pretty easily. The DS library offers a bunch (50+) algorithms to run on the graph data directly or projected, e.g. PR on 117M wikipedia links runs in 20s.
      - Grimm1 5y ago
        I've had bad experience with Neo4J's memory consumption so I'm wary of that to be honest. I don't disagree that it has those things but we actively chose to go against it because of past issues with resource usage.
- nick_ 5y ago
  Have you checked out RedisGraph extension for Redis?
tgtweak 5y ago
I always find it amusing how much graphQL there is without actual graph db behind it. Seems the concept of having fluid relationships is appealing for querying but not structuring/storing... which seems like a disconnect. I have only seen a few Neo4J systems in serious production workloads and they were ALL on logistics... I'm not sure that it's being positioned (or interpreted) as a nice simple solution to start out on. Edit: I just checked out neo4j "bloom", and it's definitely a good way to make graph more accessible - they should continue to build further on it.
- jexp 5y ago
  Not sure if you saw our graphql integration, that takes typedefs and converts a graphql query into a single cypher query, which can then be executed directly. https://neo4j.com/product/graphql-library/ https://neo4j.com/product/graphql-library/ has links to docs and api scaffolding tools. When I started back then in 2016 with it, it was pretty cool how directly graphql mapped to the graph model in the db.
  - tgtweak 5y ago
    This looks pretty cool, directly speaks to what I was talking about re: why doesn't more of this exist.
- tshaddox 5y ago
  I don’t think that’s particularly amusing or a “disconnect.” From what I can tell, the entire point of GraphQL at Facebook was to expose an interface that looks like a graph database but is in fact able to load data from any number of different underlying data stores (without the query developer needing to know about that part).
  - rdevsrex 5y ago
    To me, the best part about graphql is subscriptions over websockets.
- handrous 5y ago
jrsj 5y ago
Series F isn’t an inherently bad thing. That just means that they’ve been around for awhile, want funding to accelerate growth, and don’t want to go public. Every company doesn’t have to grow super fast after 1-2 massive funding rounds and then get acquired.
softwaredoug 5y ago
> By 2025, graph technologies will be used in 80% of data and analytics innovations, up from 10% in 2021, facilitating rapid decision making across the enterprise.” What is behind the thought that graph databases are going to grow so much in the next few years? To me they've always had a niche use... Are they really going to be ubiquitous (like this funding seems to assume?)
- handrous 5y ago
  Neo4j is all-in on, "almost everything looks like (or can be made to look like) a graph, so almost everyone should be using a graph database". As for those specific figures, I'm guessing there's enough wiggle room in "data and analytics innovations" (emphasis mine) to find or project almost any trend one wishes. What are data analytics innovations? Why, it's the set of things that will see 80% use of graph technologies! "Graph technologies" is also so potentially-vague that it could plausibly be 100% of almost anything related to software.
  - vincent-toups 5y ago
    "Everything looks like a graph" is more damning of the idea of a graph as storage than it is praise. The whole point of a database is to impose _additional_ constraints on the data to ease subsequent application development or data analysis. Relational data may be a hassle but its a hassle you end up having to deal with anyway at some point. I can see a graph database as being a useful place to stash a ton of shitty data as an initial place to start an ETL but I can't imagine using it as a system of record except in very limited situations.
    - handrous 5y ago
      Oh, I agree that, baring some actual honest-to-god innovation, the whole product category's niche-by-nature. Just relating the way Neo4j's been positioning themselves.
    - ants_a 5y ago
      The additional constraints are also what enable performance optimizations. And not the small ones, the ones that give orders of magnitude improvements. Whereas right now neo4j is slower for graphs than postgres, just with a nicer UI.
somewhereoutth 5y ago
Graph DBs work if you know your relationships of interest ahead of time, and are happy to have them baked into your dataset. With relational databases, you can join on anything anywhen, so you can explore new relationships as you go.
- speaktorob 5y ago
  That's exactly the trade off, isn't it? Either you do the work to store the relationships and save on the compute and memory cost later, or you pay as you go to build it in real time with a relational database. It's horses for courses.
  - somewhereoutth 5y ago
    It could be argued that a graph dB is just a really badly implemented index.
    - AndrewBowman 5y ago
      To propose a different perspective, a relationship in a graph db is like a materialized join. You pay on relationship creation (you might be using index lookups to find the nodes to connect, similar to a relational db), then for traversal it's just pointer hopping across the relationships to the connected nodes. Aside from the initial lookup of starting node(s), traversing the graph won't use indexes at all, so becomes constant time operations.
- DSingularity 5y ago
  > Match (a)-[:knows]-(b) > Match (b)-[:loves_to_eat]-(c) > Return a.name,c.name //food suggestions Why isn’t this sufficient to explore novel relationships?
busterarm 5y ago
The Enterprise version is ridiculously expensive. Think Oracle/IBM type of pricing. Community Edition is hobbled to the point where I wouldn't recommend anyone run it in production.
- hugofirth 5y ago
  Enterprise licenses for on premise Neo4j are certainly for a specific customers with specific needs, but there is always the DBaaS (https://neo4j.com/cloud/aura/ https://neo4j.com/cloud/aura/). Or if you absolutely need on premise and are small there is the startup program for free enterprise licenses (https://neo4j.com/startups/ https://neo4j.com/startups/)
  - busterarm 5y ago
    Neo4j's entire pricing model, even in cloud, is built around the idea that you'll have one centralized very large graph. Many companies, like the one I'm at, have the opposite use case -- many, geo-distributed, tiny graphs and multiple (read: 3-5) pre-prod environments. They simply don't have a pricing model that supports customers like us. They wanted to charge us something like 10% of our ARR for something that was just a component of one microservice.
    - zozbot234 5y ago
      "Many tiny graphs" seems like an interesting use case for Postgres or even SQLite, seeing as it also supports recursive query.
      - busterarm 5y ago
        tiny compared to the scale they're looking to sell but not exactly small. Also network-isolated. A graph db is the right tool for this use case. Just not really theirs, although it could if they could understand how to sell it to us at a fair price.
- speaktorob 5y ago
xibalba 5y ago
According to Crunchbase, Neo4j was founded in 2007! Is this correct? 14 years in and they are still raising VC money!?
- hirako2000 5y ago
  Welcome to the new economy. VC money get poured with an exit at sight. The bags keep growing until it ends up on public offering. By that time, the share is pretty much what it's worth. But 100 times round A. If all went well of course. Over 90% of the time, it didn't go well. Who knows how that will end for Neo4j, but the investors have their eggs in many other baskets anyway. What matters isn't showing profit anymore, not even significant revenue to justify further funding. All you need is some appealing growth figures, sometimes not even that, just a convincing argument that hyper growth is on the horizon. At some point millions are put into advertising and a strong sales force to grow revenue many folds. In the enterprise market, the trick often works pretty well.
- Barrin92 5y ago
  and the sheer size of these rounds always astonishes me for very specialized software products. 300 million bucks, that's enough to build a death star, what do they do with all of the cash
  - fedder 5y ago
    apparently building a new HQ, sponsoring F1 and doing a massive super bowl commercial. https://www.youtube.com/watch?v=jTGSyfvQoZ8&t=367s https://www.youtube.com/watch?v=jTGSyfvQoZ8&t=367s
    - thu2111 5y ago
      "... no obviously we're not going to do any of these things, it comes down to product, product, product"
__jem 5y ago
Curious what something like Neo4j offers over a something like [this](https://docs.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-overview?view=sql-server-ver15 https://docs.microsoft.com/en-us/sql/relational-databases/gr...) in MSSQL.
- zozbot234 5y ago
  These seem to be non-standard SQL extensions, AIUI. At least Neo4j has something of a quasi-standard solution for their querying layer, that might also be supported by other vendors. These extensions are a dead end.
  - __jem 5y ago
    I’m not sure I understand calling this a “dead end”. Almost no one limits themselves to pure ANSI SQL. Pretty much any application of reasonable size in production uses vendor specific APIs. A “quasi-standard” is not a standard. I was thinking more about technical reasons in terms of the storage layer. The query syntax seems to be the least interesting part of a database, to be perfectly honest.
- clpm4j 5y ago
  Native graph storage and index-free adjacency. No tables, no JOINs.
  - __jem 5y ago
    Okay,that seems more interesting. Any resources on the data structures used to avoid indices? Without table ddl, if node types are arbitrary, that seems like a hard problem to solve in terms of storage layout.
    - clpm4j 5y ago
      "To understand why native graph technology is so efficient, we step back in time a little to 2010 and the coining of the term index-free adjacency by Rodriguez and Neubauer. The great thing about index-free adjacency is that your graphs are (mostly) self-indexing. Given a node, the next nodes you may want to visit are implicit based on the relationships connecting it. It’s a sort of local index, which allows us to cheaply traverse the graph (very cheaply, at cost O(1) per hop). Neo4j manages to keep traversal costs so low (algorithmically and mechanically) by implementing traversals as pointer chasing. This implementation option is available to us precisely because we bear the cost of building the storage engine..."[1] "Each node (entity or attribute) in the graph database model directly and physically contains a list of relationship records that represent the relationships to other nodes. These relationship records are organized by type and direction and may hold additional attributes. Whenever you run the equivalent of a JOIN operation, the graph database uses this list, directly accessing the connected nodes and eliminating the need for expensive search-and-match computations."[2] Resources if you're curious: [1] https://neo4j.com/blog/computer-hardware-native-graph-databases/ https://neo4j.com/blog/computer-hardware-native-graph-databa... [2] https://neo4j.com/developer/graph-db-vs-rdbms/ https://neo4j.com/developer/graph-db-vs-rdbms/
nrjames 5y ago
Anybody know of a good graph extension for SQLite?
- captn3m0 5y ago
  See https://news.ycombinator.com/item?id=10991751 https://news.ycombinator.com/item?id=10991751 for some similar discussion.
- DemocracyFTW 5y ago
  https://news.ycombinator.com/item?id=25544397 https://news.ycombinator.com/item?id=25544397
motohagiography 5y ago
I've done development on an app with Neo as the back end, and what I liked about it was mainly py2neo and the cypher query language. Even after developing in it, approaching another graph in DGraph was conceptually impenetrable, as my impression of dgraph was they had a bunch of unnecessary and poor abstractions in their documentation. The next candidate is the redis graph, but I haven't. With Neo, if you learn cypher, you literally don't need to know anything else about it to be useful in it, which brings me to what I think their real market is. The opportunity I understood after using Neo was the big product play would be a kind of mental shift for enterprise data analyst users whose jobs exist in excel/powerbi today with power users using Cognos, and less devops/SaaS company/etc. I over-use Apple as an example, but if Apple entered into enterprise data products, Neo would be the kind of thing to be the underlying tech for it, as if you are an apple user, an apple'ey analytics tool would be based on users producing and reasoning about their data with graphs instead of tables, if you could imagine a kind of photoshop for data, or a fundamental conceptual change from spreadsheets to graphs. They aren't as competitive as a data tool, but I think they are unrivaled as a knowledge tool. The tech is really great, but the product piece appears to have been a challenge because the use cases for graphs have been very enterprise'y, which has limited adoption because people who operate at that higher business logic level of abstraction that graphs enable are not the people picking and adopting new technologies. The growth will come from younger people who learned python in high school, and have a more data centric world view. Maybe that's the play. Anyway, as a user I can see why they got participation on an F round. Imo, they've solved the what/how/why and have done some amazing science and engineering, and what I hope that money buys them is some magic.
- topicseed 5y ago
  Amongst all graph databases I tried, Neo would land third and last. Dgraph and ArangoDB would definitely be ahead in terms of developer experience from data loading to regular transactional use. But I do appreciate all the effort Neo4j put for years in educating us all on graph databases, use cases, and just drawing attention and awareness.
- mrjn 5y ago
  (author of Dgraph here) > my impression of dgraph was they had a bunch of unnecessary and poor abstractions in their documentation I'm surprised to hear that. Dgraph uses GraphQL (and DQL, a fork of GraphQL) as the query language -- which is a lot more widely adopted language than Cypher. Dgraph users really like the simplicity and intuitiveness of the language and ease of use of the DB. I'm curious what was confusing in documentation.
topspin 5y ago
I've been looking at Bitnine AgensGraph and thus also Apache AGE. These are (related) extensions of PostgreSQL that use PostgreSQL to implement a complete graph database and Cypher query language. Interestingly you can even mix SQL and Cypher in the same statement. This approach of extending PostgreSQL is very appealing to me. There is a great deal of value in the PostgreSQL stack that doesn't need to be reinvented just to deliver a graph database and query language. How much easier is it to adopt graph database techniques when it is simply an extension of database technology nearly everyone is already running? Conceivably one might find some future version of PostgreSQL RDS (and other cloud PostgreSQL services) delivers Cypher.
heldsteel7 5y ago
I worked on a use case which was clearly in graph in nature. So graph database seemed a natural choice, of course Neo4j was one of the most heard product even back then. We did evaluate Neo4j, but put down due to its complex query language (cypher) and slowness. It was really an awkward language, super awkward. We also evaluated arangodb and we found it much better than Neo4j. Performance was good and its query language was better too. What we realised in the process is, using graph databases is more of a cultural transformation as well. SQL is much well understood, well adopted and well supported by community. Ultimately we implemented the use case in Postgres, and thank God we did it that way. IMO, we can still get all the benefits of graphs we SQL databases with little efforts.
diveanon 5y ago
Neo4j can be a useful supplement to apps that have data models that include graphs. If you are using relational db you can use recursion to achieve the same effect without having bring n4j and cipher into your stack. A simple example of implementing a hierarchical graph data structure on postgres and exposing it via graphql can be found on the hasura blog. https://hasura.io/blog/authorization-rules-for-multi-tenant-system-google-cloud/ https://hasura.io/blog/authorization-rules-for-multi-tenant-...
- tango12 5y ago
  (from Hasura) I've been wanting to try out a thing and use Neo4j + Postgres simultaneously. Use Postgres for data, Neo4j for relationships and graph-y queries. Has anyone tried that? Would love any notes/pointers! Join data across the two to get the best of both basically. Hasura doesn't support Neo4j natively yet, but maybe using Neo4j's graphql wrapper as an input to Hasura perhaps?
cryptos 5y ago
Series F = they haven't found a sustainable business model yet?
zestyping 5y ago
I joined a small open source project that had decided to use Neo4J instead of a SQL database as its primary store. Simple queries mysteriously caused Neo4J to gobble up huge amounts of memory. Neo4J struggled even though we had fewer than a million items, sometimes getting so stuck that we had to restart the database. There wasn't any good tooling to explain why our queries were so slow. We'd already upgraded our VM beyond what we originally hoped to spend and were reluctant to spend even more on a larger one. We had a team member who had used Neo4J professionally for years and could not figure it out. And we only had one; every other teammate and new volunteer had to be trained in a strange new way of thinking about databases and a new query syntax. Setting it up to run locally for development was a difficult process. Progress was slow and our code to access the database was messy. We kept being promised that, in exchange for these heavy burdens, Neo4J would do amazing things for us once we started doing graph queries, but we never got there because it couldn't do the basics. We rewrote the project to run on PostgreSQL. Five tables, properly indexed, lightning fast, easy to set up and understandable by anyone. A hundred million rows and it didn't break a sweat, on the lowest tier of machine. Even graph queries were straightforward and quick. Advice: Don't use Neo4J as your primary store, and avoid it altogether if you want volunteer or casual contributors. For us, it was all costs and no benefits.

154 points by hugofirth 5y ago

It's always interesting to hear about huge funding rounds for companies I've never heard of. Even more so when they apparently work with a bunch of companies I have heard of.

handrous 5y ago
They're a fairly major graph database product with a well-funded sales team that has been hammering the "I mean, doesn't everything look kinda like a graph? Isn't your data kinda a graph? You should definitely use us as your database-of-record, or for literally anything else you might use a database for, look how fast we are at graph stuff!" line hard and (apparently) with great success.
- objektif 5y ago
  So are you saying sales works?
  - handrous 5y ago
    Yeah, I mean, it's not the first time a database that's best-suited to a niche use-case has successfully had its market hugely expanded by sales & marketing promoting it as a superior replacement for what are in fact better general-use products. Clearly, it's a playbook that works.
- dgb23 5y ago
  I’ve used it in production roughly 5+ years ago. Both graph data modeling and cypher queries are very fun to work with. It’s both dynamic and powerful but still gives you a decent amount of structure and ACID guarantees. One thing that is much easier to model and query, or rather more natural and simple, is authorization and other granular questions you might have about how users and data is connected. A thing that I can’t wrap my head around however is temporal data modeling with graphs. Haven’t seen or thought of anything too satisfying yet, that meshes well with how I think about graphs. Whereas in SQL it is more explored and clear to me. I agree that their marketing is very aggressive, but this tech has quite some merit.
  - LukeEF 5y ago
    check OpenCrux and TerminusDB - both time traveling graphs which specialize in temporal data modelling
- oauea 5y ago
  I'm sure it's fast, but also consumes a ridiculous amount of memory. Tried loading a smallish dataset into neo4j that runs on a 100mb ram postgres server just fine. Neo4j wanted gigabytes of memory.
  - economusty 5y ago
    Gotta love the jvm.
  - handrous 5y ago
    When I used it, it was fast at a very specific set of graph traversal operations. It was extremely easy to step outside those narrow patterns, while doing things that seemed like they should be fine and were very common sorts of things one might want to do with the DB, at which point performance would become terrible. A look at the underlying data structures they use was revealing re: why they were so fast at some things, and so slow at others. And they only achieved that much performance by, as you note, eating memory like it's free (I mean, it is Java...). It was also alarmingly weak on data-integrity protection features, like constraints, locking, and data-types, at the time. IDK, maybe they've fixed that. Then, it was IMO wholly unsuited to hosting any data set that you couldn't stand to have completely destroyed every so often (so, a very particular kind of caching, which IIRC is exactly what one of their marketing department's favorite names to trot out, Ebay, used it for then). [EDIT] I would, however, agree with nisa's post elsewhere in the thread, that the Cypher query language is excellent.
    - nisa 5y ago
      only looked through papers but this didn't look good for them (but maybe an older version - paper is from 2015): https://static.googleusercontent.com/media/research.google.com/de//pubs/archive/43287.pdf https://static.googleusercontent.com/media/research.google.c... - that's why apache age is really interesting or will be maybe one day.
  - deleted 5y ago
    [deleted]
  - detaro 5y ago
- chippiewill 5y ago
  I used to work for a database vendor. I'm getting serious 'nam style flashbacks reading your comment. The capability of sales to sell a product to massive companies for a use case that we're actually not very good at was unbelievable.
  - handrous 5y ago
    It keeps working, so I can't hardly blame companies for doing it. The people who are falling for it, on the other hand....
  - cerved 5y ago
    I used to work in IT sales and I'm not surprised

whalesalad 5y ago

> Series F Yikes > largest investment in a private database company I guess this is one of those PR moves that is trying to make something lame sound good? If your customer portfolio includes Walmart, Volvo and AstraZeneca why are you raising money a 6th time?

caturopath 5y ago
Having some department at e.g. Volvo using your product doesn't mean that you have Volvo as a serious customer paying you like they would as a serious customer. I take your point that this is a really late round of funding, but this doesn't mean they've caught on like they want to yet.
- whalesalad 5y ago
  I agree that what you've described is likely the true situation. It just looks funny to see a company claim to be worth $2 billion dollars and namedrop big brands and yet require a 6th cash injection. There is an incongruence there.
  - latenightcoding 5y ago
    But that's how most big tech companies have been operating for the last 10-15(?) years. How do you think public companies that have never made a $ got there.
    - dalbasal 5y ago
      True. Private funding rounds this big just weren't available, so these were IPOs instead of round FS.
  - dvirsky 5y ago
    Redis Labs are more or less doing the same.
httpz 5y ago
Series F by itself isn't necessarily a bad thing anymore. Uber, Lyft, Airbnb, Snowflake all had Series F rounds at one point.

haolez 5y ago

Series F? Is that a bad smell or is it considered normal nowadays? Genuine question.

hacksaw_hetty 5y ago
Normal - just take a look on crunchbase
not_jd_salinger 5y ago
Both. I personally find the fact that having these later and later rounds of funding considered normal a huge indicator that something is very wrong with the current industry. It means there's a lot of capital being dumped into trying to find some hidden source of profit and it's getting harder and harder to find it. It's the capital equivalent of going from finding oil in your back yard to blasting it out of tar sands in the Canadian tundra. Sure the capital/oil keeps flowing, but the inherent unsustainability of the system starts to show its face more clearly.
phillipcarter 5y ago
Another way I look at this is that wealth has accumulated so disproportionately at the top that the small number of individuals/firms flush with wealth need to find ways to spend the money. So why not dump hundreds of millions on another company? Since there isn't any actual force coming in to take and redistribute it, might as well spend it.
dcolkitt 5y ago
Ever since Sarbanes-Oxley there's been a continuously declining number of new public companies. The reality is the modern legal and regulatory environment makes being a public company significantly more burdensome than it was in 1995. There's more than abundant amounts of capital in private equity, so the only real reason to go public is to create liquidity for early founders/investors/employees who want to cash out. Given that, arguably you could say going public, instead of raising private capital, is the smell. Or at least an attempt to top-tick the valuation, e.g. WeWork.

nisa 5y ago

cypher is really cool and with neosemantics[1] you have the best of both worlds - labeled property graphs and rdf* they even have a cool reasoner and sparql. that being said I thought about porting it to postgresql with apache age vs. using neo4j for a project because it's faster at least for this usecase. Easier said than done, through. If you want to play with graphs and linked-data it's super cool. There is also structr[2] that builds CMIS / Alfresco ECM like functionality atop neo4j with graaljs scripts. 1: https://github.com/neo4j-labs/neosemantics https://github.com/neo4j-labs/neosemantics 2: https://github.com/structr/structr https://github.com/structr/structr

Grimm1 5y ago

What this tells me is that the graph db space has a lot of room in it for someone to come along and make a kick ass product, because honestly every time I've had a problem a graph db can solve I remember I basically only have a few mediocre choices to choose from. Neo4J has been very meh in my experience, but they are the biggest.

The_rationalist 5y ago
What make you consider Tinkerpop mediocre?
- Grimm1 5y ago
  Honestly I never heard of it, I had a few in mind but that wasn't one. I'll give it a try next time I need a graph db maybe it can scratch my itch so to speak. My concerns basically range around memory consumption, query language and language ecosystem. Edit: Oh and I guess around like functional extensibility. The last time I used a graph DB I had to export from the db itself to HDFS and use Spark to do things like PageRank and I'd rather be able to write that natively in their query lang or some like UDF equivalent.
  - jexp 5y ago
    That's what you can do in Neo pretty easily. The DS library offers a bunch (50+) algorithms to run on the graph data directly or projected, e.g. PR on 117M wikipedia links runs in 20s.
    - Grimm1 5y ago
      I've had bad experience with Neo4J's memory consumption so I'm wary of that to be honest. I don't disagree that it has those things but we actively chose to go against it because of past issues with resource usage.
nick_ 5y ago
Have you checked out RedisGraph extension for Redis?

tgtweak 5y ago

I always find it amusing how much graphQL there is without actual graph db behind it. Seems the concept of having fluid relationships is appealing for querying but not structuring/storing... which seems like a disconnect. I have only seen a few Neo4J systems in serious production workloads and they were ALL on logistics... I'm not sure that it's being positioned (or interpreted) as a nice simple solution to start out on. Edit: I just checked out neo4j "bloom", and it's definitely a good way to make graph more accessible - they should continue to build further on it.

jexp 5y ago
Not sure if you saw our graphql integration, that takes typedefs and converts a graphql query into a single cypher query, which can then be executed directly. https://neo4j.com/product/graphql-library/ https://neo4j.com/product/graphql-library/ has links to docs and api scaffolding tools. When I started back then in 2016 with it, it was pretty cool how directly graphql mapped to the graph model in the db.
- tgtweak 5y ago
  This looks pretty cool, directly speaks to what I was talking about re: why doesn't more of this exist.
tshaddox 5y ago
I don’t think that’s particularly amusing or a “disconnect.” From what I can tell, the entire point of GraphQL at Facebook was to expose an interface that looks like a graph database but is in fact able to load data from any number of different underlying data stores (without the query developer needing to know about that part).
- rdevsrex 5y ago
  To me, the best part about graphql is subscriptions over websockets.
handrous 5y ago

jrsj 5y ago

Series F isn’t an inherently bad thing. That just means that they’ve been around for awhile, want funding to accelerate growth, and don’t want to go public. Every company doesn’t have to grow super fast after 1-2 massive funding rounds and then get acquired.

softwaredoug 5y ago

> By 2025, graph technologies will be used in 80% of data and analytics innovations, up from 10% in 2021, facilitating rapid decision making across the enterprise.” What is behind the thought that graph databases are going to grow so much in the next few years? To me they've always had a niche use... Are they really going to be ubiquitous (like this funding seems to assume?)

handrous 5y ago
Neo4j is all-in on, "almost everything looks like (or can be made to look like) a graph, so almost everyone should be using a graph database". As for those specific figures, I'm guessing there's enough wiggle room in "data and analytics innovations" (emphasis mine) to find or project almost any trend one wishes. What are data analytics innovations? Why, it's the set of things that will see 80% use of graph technologies! "Graph technologies" is also so potentially-vague that it could plausibly be 100% of almost anything related to software.
- vincent-toups 5y ago
  "Everything looks like a graph" is more damning of the idea of a graph as storage than it is praise. The whole point of a database is to impose _additional_ constraints on the data to ease subsequent application development or data analysis. Relational data may be a hassle but its a hassle you end up having to deal with anyway at some point. I can see a graph database as being a useful place to stash a ton of shitty data as an initial place to start an ETL but I can't imagine using it as a system of record except in very limited situations.
  - handrous 5y ago
    Oh, I agree that, baring some actual honest-to-god innovation, the whole product category's niche-by-nature. Just relating the way Neo4j's been positioning themselves.
  - ants_a 5y ago
    The additional constraints are also what enable performance optimizations. And not the small ones, the ones that give orders of magnitude improvements. Whereas right now neo4j is slower for graphs than postgres, just with a nicer UI.

somewhereoutth 5y ago

Graph DBs work if you know your relationships of interest ahead of time, and are happy to have them baked into your dataset. With relational databases, you can join on anything anywhen, so you can explore new relationships as you go.

speaktorob 5y ago
That's exactly the trade off, isn't it? Either you do the work to store the relationships and save on the compute and memory cost later, or you pay as you go to build it in real time with a relational database. It's horses for courses.
- somewhereoutth 5y ago
  It could be argued that a graph dB is just a really badly implemented index.
  - AndrewBowman 5y ago
    To propose a different perspective, a relationship in a graph db is like a materialized join. You pay on relationship creation (you might be using index lookups to find the nodes to connect, similar to a relational db), then for traversal it's just pointer hopping across the relationships to the connected nodes. Aside from the initial lookup of starting node(s), traversing the graph won't use indexes at all, so becomes constant time operations.
DSingularity 5y ago
> Match (a)-[:knows]-(b) > Match (b)-[:loves_to_eat]-(c) > Return a.name,c.name //food suggestions Why isn’t this sufficient to explore novel relationships?

busterarm 5y ago

The Enterprise version is ridiculously expensive. Think Oracle/IBM type of pricing. Community Edition is hobbled to the point where I wouldn't recommend anyone run it in production.

hugofirth 5y ago
Enterprise licenses for on premise Neo4j are certainly for a specific customers with specific needs, but there is always the DBaaS (https://neo4j.com/cloud/aura/ https://neo4j.com/cloud/aura/). Or if you absolutely need on premise and are small there is the startup program for free enterprise licenses (https://neo4j.com/startups/ https://neo4j.com/startups/)
- busterarm 5y ago
  Neo4j's entire pricing model, even in cloud, is built around the idea that you'll have one centralized very large graph. Many companies, like the one I'm at, have the opposite use case -- many, geo-distributed, tiny graphs and multiple (read: 3-5) pre-prod environments. They simply don't have a pricing model that supports customers like us. They wanted to charge us something like 10% of our ARR for something that was just a component of one microservice.
  - zozbot234 5y ago
    "Many tiny graphs" seems like an interesting use case for Postgres or even SQLite, seeing as it also supports recursive query.
    - busterarm 5y ago
      tiny compared to the scale they're looking to sell but not exactly small. Also network-isolated. A graph db is the right tool for this use case. Just not really theirs, although it could if they could understand how to sell it to us at a fair price.
speaktorob 5y ago

xibalba 5y ago

According to Crunchbase, Neo4j was founded in 2007! Is this correct? 14 years in and they are still raising VC money!?

hirako2000 5y ago
Welcome to the new economy. VC money get poured with an exit at sight. The bags keep growing until it ends up on public offering. By that time, the share is pretty much what it's worth. But 100 times round A. If all went well of course. Over 90% of the time, it didn't go well. Who knows how that will end for Neo4j, but the investors have their eggs in many other baskets anyway. What matters isn't showing profit anymore, not even significant revenue to justify further funding. All you need is some appealing growth figures, sometimes not even that, just a convincing argument that hyper growth is on the horizon. At some point millions are put into advertising and a strong sales force to grow revenue many folds. In the enterprise market, the trick often works pretty well.
Barrin92 5y ago
and the sheer size of these rounds always astonishes me for very specialized software products. 300 million bucks, that's enough to build a death star, what do they do with all of the cash
- fedder 5y ago
  apparently building a new HQ, sponsoring F1 and doing a massive super bowl commercial. https://www.youtube.com/watch?v=jTGSyfvQoZ8&t=367s https://www.youtube.com/watch?v=jTGSyfvQoZ8&t=367s
  - thu2111 5y ago
    "... no obviously we're not going to do any of these things, it comes down to product, product, product"

__jem 5y ago

Curious what something like Neo4j offers over a something like [this](https://docs.microsoft.com/en-us/sql/relational-databases/graphs/sql-graph-overview?view=sql-server-ver15 https://docs.microsoft.com/en-us/sql/relational-databases/gr...) in MSSQL.

zozbot234 5y ago
These seem to be non-standard SQL extensions, AIUI. At least Neo4j has something of a quasi-standard solution for their querying layer, that might also be supported by other vendors. These extensions are a dead end.
- __jem 5y ago
  I’m not sure I understand calling this a “dead end”. Almost no one limits themselves to pure ANSI SQL. Pretty much any application of reasonable size in production uses vendor specific APIs. A “quasi-standard” is not a standard. I was thinking more about technical reasons in terms of the storage layer. The query syntax seems to be the least interesting part of a database, to be perfectly honest.
clpm4j 5y ago
Native graph storage and index-free adjacency. No tables, no JOINs.
- __jem 5y ago
  Okay,that seems more interesting. Any resources on the data structures used to avoid indices? Without table ddl, if node types are arbitrary, that seems like a hard problem to solve in terms of storage layout.
  - clpm4j 5y ago
    "To understand why native graph technology is so efficient, we step back in time a little to 2010 and the coining of the term index-free adjacency by Rodriguez and Neubauer. The great thing about index-free adjacency is that your graphs are (mostly) self-indexing. Given a node, the next nodes you may want to visit are implicit based on the relationships connecting it. It’s a sort of local index, which allows us to cheaply traverse the graph (very cheaply, at cost O(1) per hop). Neo4j manages to keep traversal costs so low (algorithmically and mechanically) by implementing traversals as pointer chasing. This implementation option is available to us precisely because we bear the cost of building the storage engine..."[1] "Each node (entity or attribute) in the graph database model directly and physically contains a list of relationship records that represent the relationships to other nodes. These relationship records are organized by type and direction and may hold additional attributes. Whenever you run the equivalent of a JOIN operation, the graph database uses this list, directly accessing the connected nodes and eliminating the need for expensive search-and-match computations."[2] Resources if you're curious: [1] https://neo4j.com/blog/computer-hardware-native-graph-databases/ https://neo4j.com/blog/computer-hardware-native-graph-databa... [2] https://neo4j.com/developer/graph-db-vs-rdbms/ https://neo4j.com/developer/graph-db-vs-rdbms/

nrjames 5y ago

Anybody know of a good graph extension for SQLite?

captn3m0 5y ago
See https://news.ycombinator.com/item?id=10991751 https://news.ycombinator.com/item?id=10991751 for some similar discussion.
DemocracyFTW 5y ago
https://news.ycombinator.com/item?id=25544397 https://news.ycombinator.com/item?id=25544397

motohagiography 5y ago

I've done development on an app with Neo as the back end, and what I liked about it was mainly py2neo and the cypher query language. Even after developing in it, approaching another graph in DGraph was conceptually impenetrable, as my impression of dgraph was they had a bunch of unnecessary and poor abstractions in their documentation. The next candidate is the redis graph, but I haven't. With Neo, if you learn cypher, you literally don't need to know anything else about it to be useful in it, which brings me to what I think their real market is. The opportunity I understood after using Neo was the big product play would be a kind of mental shift for enterprise data analyst users whose jobs exist in excel/powerbi today with power users using Cognos, and less devops/SaaS company/etc. I over-use Apple as an example, but if Apple entered into enterprise data products, Neo would be the kind of thing to be the underlying tech for it, as if you are an apple user, an apple'ey analytics tool would be based on users producing and reasoning about their data with graphs instead of tables, if you could imagine a kind of photoshop for data, or a fundamental conceptual change from spreadsheets to graphs. They aren't as competitive as a data tool, but I think they are unrivaled as a knowledge tool. The tech is really great, but the product piece appears to have been a challenge because the use cases for graphs have been very enterprise'y, which has limited adoption because people who operate at that higher business logic level of abstraction that graphs enable are not the people picking and adopting new technologies. The growth will come from younger people who learned python in high school, and have a more data centric world view. Maybe that's the play. Anyway, as a user I can see why they got participation on an F round. Imo, they've solved the what/how/why and have done some amazing science and engineering, and what I hope that money buys them is some magic.

topicseed 5y ago
Amongst all graph databases I tried, Neo would land third and last. Dgraph and ArangoDB would definitely be ahead in terms of developer experience from data loading to regular transactional use. But I do appreciate all the effort Neo4j put for years in educating us all on graph databases, use cases, and just drawing attention and awareness.
mrjn 5y ago
(author of Dgraph here) > my impression of dgraph was they had a bunch of unnecessary and poor abstractions in their documentation I'm surprised to hear that. Dgraph uses GraphQL (and DQL, a fork of GraphQL) as the query language -- which is a lot more widely adopted language than Cypher. Dgraph users really like the simplicity and intuitiveness of the language and ease of use of the DB. I'm curious what was confusing in documentation.

topspin 5y ago

I've been looking at Bitnine AgensGraph and thus also Apache AGE. These are (related) extensions of PostgreSQL that use PostgreSQL to implement a complete graph database and Cypher query language. Interestingly you can even mix SQL and Cypher in the same statement. This approach of extending PostgreSQL is very appealing to me. There is a great deal of value in the PostgreSQL stack that doesn't need to be reinvented just to deliver a graph database and query language. How much easier is it to adopt graph database techniques when it is simply an extension of database technology nearly everyone is already running? Conceivably one might find some future version of PostgreSQL RDS (and other cloud PostgreSQL services) delivers Cypher.

heldsteel7 5y ago

I worked on a use case which was clearly in graph in nature. So graph database seemed a natural choice, of course Neo4j was one of the most heard product even back then. We did evaluate Neo4j, but put down due to its complex query language (cypher) and slowness. It was really an awkward language, super awkward. We also evaluated arangodb and we found it much better than Neo4j. Performance was good and its query language was better too. What we realised in the process is, using graph databases is more of a cultural transformation as well. SQL is much well understood, well adopted and well supported by community. Ultimately we implemented the use case in Postgres, and thank God we did it that way. IMO, we can still get all the benefits of graphs we SQL databases with little efforts.

diveanon 5y ago

Neo4j can be a useful supplement to apps that have data models that include graphs. If you are using relational db you can use recursion to achieve the same effect without having bring n4j and cipher into your stack. A simple example of implementing a hierarchical graph data structure on postgres and exposing it via graphql can be found on the hasura blog. https://hasura.io/blog/authorization-rules-for-multi-tenant-system-google-cloud/ https://hasura.io/blog/authorization-rules-for-multi-tenant-...

tango12 5y ago
(from Hasura) I've been wanting to try out a thing and use Neo4j + Postgres simultaneously. Use Postgres for data, Neo4j for relationships and graph-y queries. Has anyone tried that? Would love any notes/pointers! Join data across the two to get the best of both basically. Hasura doesn't support Neo4j natively yet, but maybe using Neo4j's graphql wrapper as an input to Hasura perhaps?

cryptos 5y ago

Series F = they haven't found a sustainable business model yet?

zestyping 5y ago

I joined a small open source project that had decided to use Neo4J instead of a SQL database as its primary store. Simple queries mysteriously caused Neo4J to gobble up huge amounts of memory. Neo4J struggled even though we had fewer than a million items, sometimes getting so stuck that we had to restart the database. There wasn't any good tooling to explain why our queries were so slow. We'd already upgraded our VM beyond what we originally hoped to spend and were reluctant to spend even more on a larger one. We had a team member who had used Neo4J professionally for years and could not figure it out. And we only had one; every other teammate and new volunteer had to be trained in a strange new way of thinking about databases and a new query syntax. Setting it up to run locally for development was a difficult process. Progress was slow and our code to access the database was messy. We kept being promised that, in exchange for these heavy burdens, Neo4J would do amazing things for us once we started doing graph queries, but we never got there because it couldn't do the basics. We rewrote the project to run on PostgreSQL. Five tables, properly indexed, lightning fast, easy to set up and understandable by anyone. A hundred million rows and it didn't break a sweat, on the lowest tier of machine. Even graph queries were straightforward and quick. Advice: Don't use Neo4J as your primary store, and avoid it altogether if you want volunteer or casual contributors. For us, it was all costs and no benefits.