How production-ready is TypeDB?
I plan to migrate most of my businesses databases from Postgres to TypeDB, since its model is so much better for everything I do. I need to store and query a lot of data, and there are lots of proven solutions for doing these things fast in SQL. How are the benchmarks of TypeDB compared to some SQL solutions?
Another thing that I didn't see a lot of, is migrations. I expect to be changing the ontologies of my database over time, and its not so clear to me what happens if I change the types of my data that already exists.
3 Replies
Hi @Felizola, we're glad to hear that you've been enjoying using TypeDB!
On performance
In terms of performance against major databases on the market, our latest benchmark (single-threaded TPCC-C) shows that TypeDB 3 demonstrates strong throughput scalability. Against SQL databases like Postgres which have been optimised for decades, we’re catching up, but TypeDB currently runs at about 3–6x less throughput than Postgres. Against graph databases, it exhibited 20% more throughput against Neo4J at 200 warehouses and up to 70% more at 400 warehouses.
This is something we're constantly improving as we continue the ongoing effort to improve performance. With our semantic layer and query safety, we’re likely to always have a slightly lower ceiling though for pure throughput.
The benchmark has shown that TypeDB 3 has a very predictable query speed with minimal variability, enabling your user to benefit from a predictable and consistent performance profile. Additionally, it has also shown that we are able to scale our throughput really well - TypeDB showed very little deterioration even as we increased warehouses.
Schema and migration
On the schema side, TypeDB allows you to evolve your ontology safely. The system protects against invalid schema evolution, and prevents changes that would invalidate existing data, so you can make adjustments without the risk of silently breaking things.
Ecosystem and migration tooling is currently our primary product focus, and much of the engineering team is devoted to expanding what we have available here. So, it’s still limited (especially compared to SQL which has had decades of work!), but we are evolving fast.
Love this question 😄
@Felizola one of the things I've found when moving from SQL / Relational thinking to Type (Graph Structure) / TypeDB is that in relational databases there is a lot of data and complexity (e.g. 3rd Normal Form removal of dependencies) that you simply do not need with TypeDB. Its a lot simpler to model the data and the trick here is to put your 'relational' hat away and think conceptually about what you're trying to do to support the process. This will not only potentially simplify what you originally had to have in a relational database but also actually potentially significantly reduce data volumes. Also as @ganesh said the system is very good at protecting against invalid schema evolution!