ADBC driver for glaredb

[universalmind303]

Description

create an ADBC driver for glaredb.

We could do this via #1827. There is already an ADBC driver for Flight SQL, but that would be less performant than a native implementation.

Native implementations are allowed to do zero copy while Flight SQL goes over RPC.

References

• arrow-adbc

[universalmind303]

Note: If we try to do a native implementation, we will likely need to create our own rust based ADBC implementation. There currently isn't a rust ADBC implementation.

We could use extern "C" & patch into the c library, but a native rust implementation would probably be "safer"

[scsmithr]

There's some rust code in upstream ADBC repo that we could use: https://github.com/apache/arrow-adbc/tree/main/rust/src

[universalmind303]

There's some rust code in upstream ADBC repo that we could use: https://github.com/apache/arrow-adbc/tree/main/rust/src

I was looking at that the other day, It looks like it only really provides the interfaces (traits) & common structs, but isn't a full fledged driver sdk like the other languages offer. It also uses the apache_arrow crate instead of c structs, so afaik it isnt portable across languages like ADBC is supposed to be.

[tychoish]

Is there a user or a feature that would be dependent upon it?

My assumptions are that:

• for remote users, they're already always over rpc so using flightsql seems fine .
• particularly for remote use cases, the performance hit for using the flightsql wrapper is going to be minimal relative to the cost of the network.
• for development and prototyping purposes the flightsql (with it's adbc driver) is fine as a starting point (and since we want to do flightsql anyway,) and we can add this in later, if/as there are interest (or just in general, doing flightsql before adbc makes sense.
• the embedded use-cases where users have an existing adbc app that they want to use glaredb with, is probably a fairly small population.

Just to be clear, I think we should probably do this and flightsql, but given finite resources and time, we should try to do flight first.