I run the development of TypeDB, which doesnt use Cypher but works really well as a graph database. Certainly it, and other graph databases like neo4j, are used in production at scale. However, a lot of oss databases are open core on some level, it just depends on where they draw the line. We draw it at clustering/high availability for the time being, the rest is in the CE version.
Hi HN, I'm CTO at TypeDB. We shipped an agent mode in our web Studio that lets you describe what you want in plain English and get executable database queries back. The blog calls it "vibe querying," which is a little tongue-in-cheek, but the workflow is what you expect: ask a question, get TypeQL, run it, iterate.
TypeDB's data model has a strict schema, higher-level abstractions (role-based interfaces, subtyping & inheritance), and hypergraph structures (n-ary relations & relations in relations) built in. This combination enables better AI query generation.
It's like giving the LLM a strongly typed language instead of a loosely typed one. With a relational db, the model has to infer relationships from foreign keys and naming conventions. With graph databases, there's no enforced schema. In TypeDB, the schema says "friendship is a relation with two friends, each played by a person" — the LLM gets a constraint space to navigate rather than guess at. It still gets things wrong — the post shows a syntax error it had to recover from — but the error surface is smaller and more correctable.
Would love to hear your thoughts. Happy to answer anything about TypeDB as well!
I wanted to jump in here and say that what we're working on at typedb.com, in our 3.0 version (coming soon in alpha!), is that we're taking our earlier database query language and making it much more Programming-like: functions, errors containing stack traces, more sophisticated type inference, queries as streams/pipelines... I think it's super exciting and has a huge horizon for where it could go by meshing more ideas from PL design :)
Incidentally I think it also addresses what a lot of the comments here are talking about: not learning JOINs, indexing, build-in relation cardinality constraints, etc, but that's a separate point!
> TypeDB models are described by types, defined in a schema as templates for data instances, analogous to classes. Each user-defined type extends one of three root types: entity, relation, and attribute, or a previously user-defined type.
This sounds like an EAV table, which is generally a bad idea.
Re: types, Postgres allows you to define whatever kind of type you’d like. Also re: inheritance, again, Postgres tables can inherit a parent. Not just FK linking, but literally schema inheritance. It’s rare that you’d want to do this, but you can.
In general, my view is that the supposed impedance mismatch is a good thing, and if anything, it forces the dev to think about less complicated ways to model their data. The relational model has stuck around because it’s incredibly good, not because nothing better has come around.
EDIT: this came across as quite harsh, and I’m sorry for the tone. Making a new product is hard. I’m just very jaded about anything trying to replace SQL, because I love it, it’s near-universal, and it hasn’t (nor is likely to) gone anywhere for quite some time.
We've started to formalise TypeQL (TypeDB's query language) using dependent type theory, which fit together very nicely. Interestingly, the formalisation shows us how to consistently and safely extend the language with new structures for higher levels of expressivity, which is a huge benefit of type theoretic formalisms of production languages IMO.
I work on TypeDB (https://vaticle.com/typedb), and it sits somewhere at this intersection. The exposed query language has elements of both logic programming constructs and graph-like structures. Both amount to a kind of "constraint" programming.
A quick peek shows it seems along similar lines as TerminusDB sorta kinda, but they have WOQL [0]. At this time I start to worry again about all the different kinds and flavours of query languages that are emerging.
Agree, only concern is that whatever emerges here has conceptual clarity and doesn't get bastardized by people who haven't studied the foundations of the relational model.
I have this fear because there's a history of that with novel query languages and DB platforms tossing in network/hierarchical/"document"/object-oriented features, and creating a dog's breakfast which loses the compositional/expressive power of the relational algebra. Think MongoDB or Redis. Conceptually a big mess.
RDF itself has a history of this as well. Appeals to novelty.
Or even Google's F1, which smashes hierarchical tree-structured protobufs into a SQL DB, and so has really weird behaviour on joins and projections.
Well, whatever, you know my opinions on this stuff, I think :-)
At this point I'd settle (or ask for) for a network available tuplestore which just receives relational-algebraic operators from a client, and optimizes/executes, and returns pure tuples, and the client-side could formulate whatever query language (or API) it wanted on top of that. I started playing with building something like that between the two jobs, but never got far.
I've had these for about 12 years, they don't get mentioned enough!
Downsides were that in the US there were expensive, and need proper daily cleaning, but the tradeoff is worth it - only need 1 pair per year - less waste too!
Going to get Lasik this year because they don't play nicely with travel in developing countries, but they were absolutely fantastic for school and university.
I think that you're correct in your assessment of relational vs graph-like structures: it's closer to our data domains we model and think of, more flexible, etc. We may be seeing something similar in the ML world where things are moving from tabular-dominant data to being able to process graphs more natively. A table is just a very structured graph after all!
SQL is the standard because, as others have pointed out, it's so entrenched and also builds upon a solid theoretical foundation. And given its dominance, it has been optimised and performed extremely well until recently, where data complexity is catching up again.
Recent noSQL databases won't take over SQL because of the lack of schema/typing. They do scale nicely, but aren't as constrainable as SQL, which is a feature (compare building a large software in Python vs Rust or Java) that enforces safety and good abstractions. There are some newer DBs which are combining strict schemas with NoSQL, which is promising!
Disclaimer: I work on TypeDB (vaticle.com/typedb) which is a native ERA (entity-relation-attribute) model with strict typing via the schema.
Same question! As I understand it:
CO2 pulled out of the ocean is replenished by atmospheric CO2, because limestone in the ocean dissolves too slowly to make up for the imbalance and it more readily comes in from the air.
But if that's true, then the calcium will actually not be replenished quickly in the ocean (not sure what the significance of this is)!
If it were true that the calcium is dissolved fast enough to replenish, then there must also be CO2 released from underwater limestone? Which means extracting Ca and CO2 will not remove any atmospheric CO2 really.
Alternatively, we do end up extracting Ca from the ocean that is not replenished (there's probably so much we don't care) and rely on the atmospheric CO2 to correct ph balance of the ocean?
