# Status of Julia database libraries

**URL:** <https://discourse.julialang.org/t/status-of-julia-database-libraries/11877>\
**Category:** General Usage\
**Created:** [June 22, 2018, 9:34am UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877 "2018-06-22T09:34:42Z")\
**Posts on this page:** 20\
**Page:** 7

<div class="post-metadata">

**Author:** ![randyzwitch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/randyzwitch/32/15955_2.png) [@randyzwitch](https://discourse.julialang.org/u/randyzwitch)\
**Post date:** [August 5, 2019, 4:47pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/124 "2019-08-05T16:47:03Z")

</div>

> [@quinnj](#):
>
> So in short, I’d really be interested to hear why people think this is so important and what other value they get out of having something like DBAPI

Agreed. This is a chicken-egg scenario. R has their DBI, which allows packages like dbplyr to exist, and Python has Ibis (which is a bit less successful). Since there really isn’t a 500-lb gorilla in the Julia community yet like RStudio, the commonality is less important because no one is trying to catch up to an instant eco-system.

FWIW, as someone who is thinking about making a DBI-compliant R package, it sucks. Being DBI compliant for Python isn’t much better (just to the extent that Python is somewhat easier than R to develop packages). So without a really compelling use case, I don’t see Julia having a DBI-like package any time soon

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [August 5, 2019, 7:37pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/125 "2019-08-05T19:37:31Z")

</div>

> [@quinnj](#):
>
> A lot of people over the years have commented on the desire/need for something like DBAPI; I’m really curious why people feel this would be so important? I mean, I get the “common API for any database” obvious answer, but when I think about this more realistically, I just don’t know if I see the value

The value of it depends a lot on the circumstances in which you’ve landed yourself. At some point, in my job, there was a whole mess of different databases (or query interfaces at least) which I might have to use at any given time: Postgres, MS SQL, presto, AWS Athena. There were indeed times when I would be asked to “swap” between them. In this sort of environment the DBAPI felt important: if a different database is to be used, the interface has to change, usually in a whole bunch of different places all at once. I still believe that a general interface would be a good thing to have. Granted, it’ll be more valuable to some than for others.

There was a time when this was highly relevant to me and I had every intention of taking this on myself. I was waiting for the Julia data ecosystem to mature somewhat, but by the time that happened, my own need for this was dreceasing drastically (I was working on a major project that was going to be all Postgres and another that was just fetching data directly from REST API’s on demand).

Right now I’m finding myself in the position of needing more new ways of fetching data. At the moment my colleagues seem increasingly eager to use Databricks for everything (Databricks is something I’m extremely skeptical about for all sorts of reasons). I don’t know what the future of interacting with that will look like for me, but it’s likely to remain true that I will not have the need for a DBAPI that I would have had two years ago.

My biggest concern by far right now is that we have ~~effectively lost the JDBC wrapper until Julia 2.0~~. JDBC was a really nice fallback because you can always be confident that a driver would be available for it. Beyond that, at least where I am I see an increasing reliance on Spark, which suggests that I might increasingly have to pull in the entire JVM as a dependency in any case, so knowing that you can essentially interact with both Spark and databases in a straightforward way through JavaCall in Julia was highly valuable, and it’s all gone for the foreseeable future. Lately I’ve been contemplating how much I’ll need to use SQLAlchemy through PyCall.jl as an alternative.

( **NOTE:** @StefanKarpinski has indicated that it is not necessarily true that this issue can have no satisfactory resolution until 2.0, so please ignore that particular implication in my text above.)

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [August 6, 2019, 3:18pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/126 "2019-08-06T15:18:30Z")

</div>

On DBAPI abstraction, I’m not pushing anyone, but it seems like a simple thing? Just make at least one function “query” generic (more?) would go a long way. I’m not sure, can a macro help? And more importantly, because of e.g. JDBC issue, could the abstraction, not only abstract away the database type, but also make it easy to switch between JDBC.jl, SQLAlchemy through Python, ODBC.jl (or is that the only point of this package?) and native drivers?

> [@ExpandingMan](#):
>
> My biggest concern by far right now is that we have effectively lost the JDBC wrapper until Julia 2.0.

I quoted this in my latest discourse thread, and asked about a (possibly) more general issue this JavaCall/JDBC issue.

You probably know best about JDBC.jl, but it’s not really lost, if you are ok with using the long-term support (LTS) versions of Julia, 1.0.x; or if you wait for at least 1.4, as 1.3 is heading for feature freeze, and release of 1.2 (and 1.3) on about 10th of August.

It’s not likely that you have to wait for Julia 2.0 at least.

I’ve not looked into this obscure PyCall issue that affects JDBC, Spark/Scala and e.g. [GitHub - aviks/Taro.jl: Read and write Excel, Word and PDF documents in Julia](https://github.com/aviks/Taro.jl) but I understand it to be on the updated JVM side and can you just use an older JVM?

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [August 6, 2019, 3:28pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/127 "2019-08-06T15:28:44Z")

</div>

> [@Palli](#):
>
> You probably know best about JDBC.jl, but it’s not really lost, if you are ok with using the long-term support (LTS) versions of Julia, 1.0.x; or if you wait for at least 1.4, as 1.3 is heading for feature freeze, and release of 1.2 (and 1.3) on about 10th of August.

My understanding is that until 2.0 one will require a custom-compiled version of Julia. At 2.0, assuming somebody does the PR for it, there will be an additional option for `ccall` which makes it possible to call the JVM without conflict. If I’m wrong about this, please somebody correct me.

Since I’m much more actively involved with Julia than anything else, for me it would be extremely painful to have to use the LTS version of Julia. It would probably already break some of my code. I will custom compile if I absolutely have to, but where I work our deployment process is already horribly broken, so I’m avoiding this as long as I can.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [August 6, 2019, 3:37pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/128 "2019-08-06T15:37:07Z")

</div>

Where in the world did the idea that this has to wait until 2.0 come from? None of this has anything to do with Julia’s API. Adding an option to ccall is not even a breaking change.

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [August 6, 2019, 3:48pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/129 "2019-08-06T15:48:41Z")

</div>

I’m so confused, this is how I interpreted the discussion in the issues. Could you enlighten us with a comprehensive description of what can happen here?

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [August 6, 2019, 3:57pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/130 "2019-08-06T15:57:20Z")

</div>

Thread title changed at OP’s request.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [August 6, 2019, 3:58pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/131 "2019-08-06T15:58:30Z")

</div>

> <https://github.com/JuliaLang/julia/issues/31104>
>
> In 1.1, trying to initialise the java virtual machine in Julia via JavaCall.jl c…auses a stack overflow error. It works correctly when the code is loaded with \`-i\` or \`-e\` but fails when used from the REPL. 
> 
> \`\`\`
> ERROR: StackOverflowError:
> Stacktrace:
> \[1\] init(::Array{String,1}) at /Users/rene/.julia/packages/JavaCall/toamy/src/jvm.jl:176
> \[2\] top-level scope at none:0
> \`\`\`
> 
> Ref: https://github.com/JuliaInterop/JavaCall.jl/issues/96
> 
> The call in question is the \`JNI\_CreateJavaVM\` function in the JVM. More information about the JVM invocation API is at https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html
> 
> This is a regression from 1.0.x

Julia 2.0 is mentioned nowhere. Also being discussed over here:

> [@Compatibility across Julia 1+ versions](https://discourse.julialang.org/t/compatibility-across-julia-1-versions/27196):
>
> I saw in a thread: “we have effectively lost the JDBC wrapper until Julia 2.0”. This isn’t strictly true, as it still works in Julia 1.0.x, the LTS versions for the foreseeable future. But, yes, Julia 1.1, if I recall, broke JavaCall.jl and thus JDBC and I guess Scala/Spark too. [And for JDBC there are workarounds.] I’ve promoted Julia’s “syntax stability guarantee”, since Julia 0.7. I do occationally see packages being fixed for 1.1, 1.2 or 1.3. I realize there can be changes in the standard…

The only place that I can see anyone talk about “we have effectively lost the JDBC wrapper until Julia 2.0” is your post that said that. Where are you getting this idea from?

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [August 6, 2019, 4:59pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/132 "2019-08-06T16:59:44Z")

</div>

Clearly I thought that someone was implying that. I’d be happy to delete any posts I made to that effect if you think this really is wrong. I’m pretty sure there is another Julia issue that discusses it somewhere, but I’m not sure which.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [August 6, 2019, 8:01pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/133 "2019-08-06T20:01:07Z")

</div>

Maybe edit your post to indicate that this isn’t the case. I talked with Jeff, Jameson and Keno earlier today and they agree that there’s no reason this would be impossible before 2.0. Nor would 2.0 somehow make it possible without modifying the JVM.

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [August 6, 2019, 8:07pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/134 "2019-08-06T20:07:11Z")

</div>

I’ll do that. Just so I’m less confused in general, what exactly would the plan be here? Is it indeed the case that what’s needed is an alternate `ccall` or an option to `ccall` and that could be introduced in 1.4?

I think it goes without saying that it’ll always be somewhat problematic if either the JVM, Julia or both always require custom compilations for this to work, though I’m not necessarily claiming there is a way around that.

(I’m feeling particularly feckless and useless here as this is something that’s potentially of really major consequence to me, but I’m totally out of my depth on the actual problem, so I’m likely to contribute absolutely nothing to the whole issue rather than standing around feeling upset 😞. Might be a good reason to get more educated on LLVM and threading.)

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [August 6, 2019, 8:08pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/135 "2019-08-06T20:08:38Z")

</div>

I’m reading the same thread that you are, the situation is laid out there better than I could explain it.

---

<div class="post-metadata">

**Author:** ![Liso](https://avatars.discourse-cdn.com/v4/letter/l/898d66/32.png) [@Liso](https://discourse.julialang.org/u/Liso)\
**Post date:** [February 8, 2020, 5:36pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/136 "2020-02-08T17:36:25Z")

</div>

@ExpandingMan I re-read that [issue](https://github.com/JuliaLang/julia/issues/31104) and see it had 1.3 milestone than 1.4 milestone and now it is without any. I am just curious if you dig up more information about this problem.

---

<div class="post-metadata">

**Author:** ![Liso](https://avatars.discourse-cdn.com/v4/letter/l/898d66/32.png) [@Liso](https://discourse.julialang.org/u/Liso)\
**Post date:** [February 8, 2020, 7:07pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/137 "2020-02-08T19:07:13Z")

</div>

> [@quinnj](#):
>
> A lot of people over the years have commented on the desire/need for something like DBAPI; I’m really curious why people feel this would be so important? I mean, I get the “common API for any database” obvious answer, but when I think about this more realistically, I just don’t know if I see the value. In various workflows over the years, I’ve worked with a specific database here, or another there, but rarely have I been in the case where I literally need to swap out exact commands from one database to another; in cases where the database does need to be changed, it usually requires a significant refactoring anyway, so swapping out the “connect” and “query” commands is usually the easiest part (vs. table creation + column type differences, syntax changes, different supported sql functions, etc.). So in short, I’d really be interested to hear why people think this is so important and what other value they get out of having something like DBAPI

You are also writing:

> [@quinnj](#):
>
> The all-time hardest thing maintaining ODBC.jl is the never-ending bug reports for specific database vendor issues that are almost impossible for me as a maintainer to reproduce or diagnose.

From [wiki](https://en.wikipedia.org/wiki/Open_Database_Connectivity): _… ( **ODBC** ) is a standard application programming interface (API) for accessing database management systems (DBMS) .The designers of ODBC aimed to make it independent of database systems and operating systems._

I think same or similar motivation could be written for ODBC than for julia DBAPI.

And you could also try to search how python DBAPI is useful.

Think for example panda’s people (see [read\_sql](https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.read_sql.html))! They don’t need to maintain different DB interfaces for people who wants to read data from DB into Dataframe.

Their users (data scientists) usualy don’t need to refactor `select * from data_table` if they have need to analyze data stored in PostgreSQL or sqlite or whatever DB. I am talking about [premature optimization](https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize) in problems where loading data from DB is just non significant part of task.

---

<div class="post-metadata">

**Author:** ![braamvandyk](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/braamvandyk/32/5086_2.png) [@braamvandyk](https://discourse.julialang.org/u/braamvandyk)\
**Post date:** [February 9, 2020, 10:52am UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/138 "2020-02-09T10:52:18Z")

</div>

I am only am occasional database user, so pardon the obvious ignorance, but with ODBC already a standard API and already available in Julia, what would DBAPI.jl add? Support for databases that choose not to follow this standard? Which ones would these be?

As I said, I don’t use these too often, so this is not an attempt to toss a pebble in the pond. I’m just curious.

---

<div class="post-metadata">

**Author:** ![Liso](https://avatars.discourse-cdn.com/v4/letter/l/898d66/32.png) [@Liso](https://discourse.julialang.org/u/Liso)\
**Post date:** [February 9, 2020, 2:19pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/139 "2020-02-09T14:19:40Z")

</div>

Look what ODBC.jl [say](https://github.com/JuliaDatabases/ODBC.jl/blob/master/docs/src/index.md):

> The `ODBC.jl` package provides high-level julia functionality over the low-level ODBC API middleware. In particular, the package allows making connections with any database that has a valid ODBC driver, sending SQL queries to those databases, and streaming the results into a variety of data sinks.

So you already have/need some julia way how to access and work on DB.

You have three options:  
a) make some standard protocol (simplest is borrow or get inspired by some useful one)  
b) keep liberty for package developers to guess or win some de facto standard  
c) ignore standardization and enjoy possibility that everything could be optimized (or screwed) in different way

ODBC.jl is probably (who knows?) using DBInterface where as I see now quinnj made this year this [commit](https://github.com/JuliaDatabases/DBInterface.jl/commit/235f9e4f30aa08abcaf425c252663ed1b74f9dfa). So maybe we are in b) situation now?

I prefer a) but I am not complaining that we are not there! It needs some kind of maturity of language and community. I was just trying to answer question why it is useful to have (some day) good julia standard DB API.

About your question - you need to install and configure ODBC drivers and environment (and also maintain it then) to use it. Some ODBC driver are not free (which could or could not be a problem).

For example think about people who are using python + DB client + DBAPI package. Now if they are thinking about trying julia - they have additional complication. (They need to install and configure ODBC drivers or install pycall and try to glue it with python dbapi package or download data from DB to file using python , … ).

Think again about pandas developers. They could say: “Hey put SQL statement and DBAPI object into our function and it will work” instead of “Please forget about your favorite DBAPI package install and configure ODBC driver and you could use it in our function”.

* * *

Look at doc for [ODBC.jl](http://juliadatabases.github.io/ODBC.jl/stable/#ODBC.load-1) function load is without asterisk `load`. An doc for [LibPQ.jl](https://invenia.github.io/LibPQ.jl/stable/pages/api/#LibPQ.load!) function load is with asterisk `load!`. You could see that if you start with ODBC (which seems to have pretty simplistic API - you really could not close connection to DB??) and wants to port program to using LibPQ.jl (not only because you need to clean memory from unnecessary connections) you have compatibility problems.

BTW I am pretty confused that `load` or `load!` function is used to save (!) data into database. (ODBC.jl doc is saying: _“… it allows one to **send** data to a DB.”_. (load and send are quite oposite for me but it could be just me! 🙂 )) LibPQ.jl doc is going from my POV more confusing (for me!) way by describe this function `LibPQ.load!(table, connection::LibPQ.Connection, query)` where `query` parameter is **insert statement**!

I don’t want to dishonest people who create packages and docs!!! I just like to show example where maybe some kind of constructive cooperation could be useful. Useful not to discourage some from using julia and help others to have best experience.

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [February 10, 2020, 2:41pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/140 "2020-02-10T14:41:29Z")

</div>

@Liso, the issue with the JVM has been resolved by providing the environment veriable `JULIA_COPY_STACKS`. If this is set to `1` the JVM should work, at a small performance penalty for multi-threaded routines. You can indeed use JavaCall.jl and JDBC.jl now on 1.3 on. I believe there was some discussion about whether a slightly different C calling convention to make this work better, but I’m not sure if there is still an issue up for that.

---

<div class="post-metadata">

**Author:** ![systems](https://avatars.discourse-cdn.com/v4/letter/s/65b543/32.png) [@systems](https://discourse.julialang.org/u/systems)\
**Post date:** [October 14, 2020, 10:28pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/141 "2020-10-14T22:28:39Z")

</div>

Sorry to revive this old post, but is ` JDBC.jl` currently the way to go for using databases from Julia?

---

<div class="post-metadata">

**Author:** ![avik](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/avik/32/17_2.png) [@avik](https://discourse.julialang.org/u/avik)\
**Post date:** [October 14, 2020, 11:09pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/142 "2020-10-14T23:09:30Z")

</div>

Depends on the Database, and your environment.

For many common databases, such as Mysql, Postgres, SQLite, there are specific drivers. For less common databases, you can use ODBC.jl or JDBC.jl based on your familiraty. If a JVM is already installed in your environment, JDBC.jl is pretty easy to use.

---

<div class="post-metadata">

**Author:** ![anon91151494](https://avatars.discourse-cdn.com/v4/letter/a/838e76/32.png) [@anon91151494](https://discourse.julialang.org/u/anon91151494)\
**Post date:** [October 22, 2024, 6:13pm UTC](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877/143 "2024-10-22T18:13:12Z")

</div>

I found this thread while doing some research regarding how well (or not well?) Julia supports interfacing with postgres.

It’s been a number of years and it looks like this thread went quiet. Does that mean support was significantly improved? I found this package called `libpg.jl`, but perhaps there’s something else which is suggested to use?

- [LibPQ · Julia Packages](https://juliapackages.com/p/libpq)

It looks like there are also two other libraries.

- [PostgreSQL · Julia Packages](https://juliapackages.com/c/postgresql)
- [Postgres · Julia Packages](https://juliapackages.com/p/postgres)

I’m not sure what the differences between these things are. If someone happens to be familiar and can tell me that would be much appreciated. Will try to figure it out of course…

_ **btw I saw some strange comments about SQL databases not being widely used** _

- Back in 2018 I was working in a research science field on a nuclear physics experiment
- The data from this experiment was stored in flat files, essentially a highly compressed binary format. The people involved in the experiment were not using SQL, but they were investigating using it for the next generation of experiments
- There were two reasons for this. They struggled to manage data using the existing simple approach, which consisted of flat files and some directory structure. Also, the rest of the experimental physics world was starting to adopt these kind of technologies. They were still years (decades) behind the software and technology world, but they had recognized that managing large quantities of data becomes easier when you use technology to do it for you.
- There were several problems with flat files. You usually end up with a large number of them, and need to index them somehow. A SQL database is ideal for this indexing purpose.
- Metadata is difficult to manage with flat files, but trivial to manage by creating ad-hoc database tables.
- Given these considerations I would imagine SQL is now widely used across the scientific research world. Larger research collaborations were of course using it long before we were looking at it. We were decades behind CERN for example.

A few reflections from industry:

- SQL is about the simplest kind of data storage technology which exists with the exception of files on disk.
- If you work for any kind of technology or software company you will encounter them from day 1.
- My first job after the research physics was working for a fintech. SQL was pretty much the first thing I learned while working there. It wasn’t hard to learn, it didn’t take long to learn (maybe a week to become pretty competent)
- The current state is that SQL is actually considered pretty uninteresting. By which I mean it’s a general purpose tool. There are all kinds of niche data storage technologies available now, each one tuned and designed for a slightly different context and application. This is necessary to get many times the performance for certain types of data operations than something like a relational database can provide. This isn’t even the frontier. These niche technology products have been around for quite some time now.

I hope these reflections offer some useful and interesting insight.

Just my opinion: To say _scientists avoid SQL_ is a bit like saying _scientists only use Fortran_.

There was a time when such statements were generally true, but to say such a thing in 2024 (or even 2018, probably) is a bit like saying in 2010 _I only know Fortran and haven’t learned either C++ or Python yet_.

I _was_ a scientist in 2018 and I _was not_ using SQL, but to say that is _really quite embarrassing_ as it’s such a simple and ubiquitous technology that everyone with any technical knowledge of programming should understand how to use it.

[Previous page](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877.md?page=6)

[Next page](https://discourse.julialang.org/t/status-of-julia-database-libraries/11877.md?page=8)