The naming of JuliaDB.jl


Are these two different projects with the same name:?

Do you have any benchmark (or comparison of features) against sqlite, data.table, feather, fst or monetdb?

Does it use compression?

One of these is an organization the other is a project. Still the name clash is not ideal. Honestly, we’ve tried forever to come up with a different name for JuliaDB, but nothing else has stuck, so in the interest of getting it out there, we decided to just go with the working name that we’ve been using internally. There are three options:

  1. Both the org and the project can use the name “JuliaDB” and they can be disambiguated contextually.
  2. The org could be renamed to “JuliaDatabases”, which is arguably a more apt name.
  3. The project could be renamed to something else – we’re open to suggestions.

An aspect of understanding JuliaDB is that, compared to traditional SQL databases, which are all about transactional storage, JuliaDB is more about persistent computation and bringing code to data efficiently and seamlessly – including being able to store any kind of Julia data without fuss. So the “Julia” part in the name can be thought of as putting a strong emphasis on code.

1 Like

GitHub - JuliaData/JuliaDB.jl: Parallel analytical database in pure Julia is a package, whereas is an organization under which there are many database driver libraries. This could be confusing, and I think technically the plural JuliaDatabases is a more appropriate name for the organization.

Do you have any benchmark (or comparison of features) against sqlite, data.table, feather, fst or monetdb?

Not as of now, but we’re working on it. The candidates for comparison we are considering are pandas.Series and xts, (maybe also data.table) which are columnar in-memory databases in the same design space as JuliaDB.jl, rather than sqlite.

[quote=“StefanKarpinski, post:14, topic:3564, full:true”]
Honestly, we’ve tried forever to come up with a different name for JuliaDB, but nothing else has stuck[/quote]
DistributedBytes.jl as suggested above?

I think that @ChrisRackauckas was suggesting “Julia Distributed Bytes” as a backronym for JuliaDB rather than suggesting that we change the name to DistributedBytes.jl. Personally, I’d be rather confused if I found a package named distributed bytes and it was a database. OTOH, I’m not sure what I would expect it to be.

I almost feel a non descriptive name like “Pandas” or “Hadoop” or something like that would be best for JuliaDB.jl (i.e. the package). It seems like a product that doesn’t just emulate something that exists already, and it combines a lot of different things into quite a unique, new thing, and I almost feel that any combination of existing terms will just point folks in the wrong direction as to what the package actually is.


Yeah, I was partially kidding to address @davidanthoff’s concerns that the name should have distributed in there. I say partially because I too am at least slightly confused by the name, and at least that interpretation worked :slight_smile:.

That should be done anyways IMO


How about Judid for Julia Distributed Database.

(Or are we over the whole “let’s just use some first name” thing ? :slight_smile: )

1 Like

I’m pretty happy with JuliaDB.jl for a name.

A Julia version of Pandas? Judid?


Judas? [ducks and runs]

1 Like

JuliaFin, JuliaRun, JuliaPro… JuliaFlow?

1 Like

Honestly, I’m still amazed that no one has jumped on the blindingly obvious JuliaSet.jl :wink:



  JuliaDB          JuliaFlex  
       DTable           FlexTable

Juice.jl (The glass looks like a database. That’s why)

Sorry for the off-topic but are there any plans for the core team to officially support the low-level libraries for the main relational databases? For example, the most complete PostgreSQL library ( is abandonware for almost year and lacks useful features (like pub/sub).

Half-joking of course (especially since I can’t think of anything better either), but shouldn’t it be avoided to use Julia in the package name? :wink:


One must assume that “the package is connected to, or endorsed by, contributors to the Julia language itself” :slight_smile:


What anout ODBC.jl?

From my perspective, using ODBC drivers for web apps is very rare. I don’t think it’s a common approach with any modern web development stack (certainly not Ruby, PHP, JavaScript, etc). Not even ASP.NET as far as I remember.

But I guess this can be a way to go if we can’t have up to date libraries wrapping the C API. Thanks for the tip.