Discussion Forum

Migrating from SQL to TypeDB

Is there a tool that can help me automate the process of migrating my data from an SQL database to TypeDB?

Hey there,

There is not a tool for direct migration as TypeDB uses a schema defined by the user, and since SQL databases don’t allow for hyper-relations, roles or rules, you would end up not taking advantage of the benefits of TypeDB.

It is always best to start by defining your schema and then look at tools like TypeDB Loader for the ingestion of data in your TypeDB database.

The problem I face is that I don’t know the schema of the SQL database to create an analogous TypeDB one. Rules are not a problem. Can’t hyper-relations and roles be inferred?

We haven’t got a way to automate the process of creating the schema because it’s very difficult to guess a good model of your domain :slight_smile: Normally we recommend sitting with the domain expert who understands the domain and engineer the ideal schema, then migrate the data into that new data model!

Interesting you don’t know the schema - I know you can extract it from the SQL table definitions. Does that mean you’re not entirely sure what your data represents either?

The developer who developed the system did it 20 years ago. He is not easy to reach and the only thing he could provide me were the c++ files that send the instructions to create the tables. He also provided me with instructions on how to save the data in a file. I know the kind of data that the database is supposed to store but lack of proper documentation makes it very difficult. I may be able to make something out of the c++ files since they contain the commands for the table definitions but it is a tedious process and I am not really sure if the table names, as written in the source code represent the actual names of the data. From what I understand they tried to create a graph database and store its contends in an SQL database.

It is VERY common in enterprise relational databases to have incomplete, ambiguous, inconsistent, contrary, or non-existent data design documentation. In fact, often it is impossible to extract the meaning from an existing database as much of the “schema” is often hardwired into the application itself. Worse, string fields often get commandeered to store ad-hoc keywords which become inconsistent and unusable over time. And then there is the sheer size of enterprise applications: it is not uncommon to have 20,000 tables or more!

1 Like

Yep. That’s what I have to deal with. My plan is to hijack the signals going into the SQL database and send them to TypeDB. Is there any way for TypeDB to infer the relationships of the data coming into it?

One of the value props of TypeDB is you can incrementially grow your schema over time – so you can start with migrating just one portion of your sql world and incorporate more as you need it!

I’m not sure what you mean by “infer the relations of the data coming into it” since the only way to send data into typeDB is with insert queries, which you have to write/template yourself.

With rules you can do some inference of course.