Live data from Hacker News

DuckDB – An embeddable SQL database like SQLite, but supports Postgres features

duckdb.org

41–50 of 167 posts

Re: DuckDB – An embeddable SQL database like SQLite, but supports Postgres features

#41
post #12
post #4

Strict typing has been the one big feature missing from SQLite, that this presumably brings.

Foreign keys enabled by default or by configuration setting would be another big feature missing from SQLite3, but I couldn't find any mention of foreign keys in DuckDB's documentation.

Foreign keys are not supported yet in DuckDB currently, but we do plan to add support for them in the future. If you have a need for them, feel free to post a comment on the issue. We tend to prioritize implementing features that many people ask for :)

Re: DuckDB – An embeddable SQL database like SQLite, but supports Postgres features

#42
post #22

I spent a while looking at this today. It's really interesting. It's not based on SQLite at all (except for borrowing the SQLite shell implementation) but it looks very much like SQLite, in particular: - It's designed to work as an embedded library, eliminating the network overhead you usually get when talking to a database - Each database is a single file on disk - It ships as an "amalgamation" build - a single gian…

How might one go about using this in a language that’s not supported in the documentation such as golang?

Re: DuckDB – An embeddable SQL database like SQLite, but supports Postgres features

#43

Earlier quoted context omitted.

> - Each database is a single file on disk Are these architecture independent? i.e. If I create the database on x86_64 and move it to ARM64; would it work seamlessly?

One of the authors here - portability of the storage is indeed one of our goals. We test that the same file can be loaded everywhere on different systems, including between ARM and x86. I should mention the storage is still very much a work-in-progress. We are actively working on redesigning the storage to add compression and other extra features, meaning the storage format can change and be incompatible between diff…

Thanks for the confirmation on portability, I didn't see Go support in the home page; Is there an official Go driver support planned as well?

Re: DuckDB – An embeddable SQL database like SQLite, but supports Postgres features

#44

Earlier quoted context omitted.

One of the authors here - portability of the storage is indeed one of our goals. We test that the same file can be loaded everywhere on different systems, including between ARM and x86. I should mention the storage is still very much a work-in-progress. We are actively working on redesigning the storage to add compression and other extra features, meaning the storage format can change and be incompatible between diff…

Thanks for the confirmation on portability, I didn't see Go support in the home page; Is there an official Go driver support planned as well?

Neither Hannes nor me are very experienced with Go, so we are not the most suitable to do that. We do very much welcome external contributions, and someone did make a WIP go driver [1] in the past.

We also have a sqlite3 compatible C API that can be used to use DuckDB. This is actually how we use the sqlite3 shell: we directly use the sqlite shell but bind it to the duckdb library using this API. It might be possible to use the Go SQLite driver in a similar manner to talk to DuckDB.

[1] https://github.com/marcboeker/go-duckdb

Re: DuckDB – An embeddable SQL database like SQLite, but supports Postgres features

#45
post #42
post #22

I spent a while looking at this today. It's really interesting. It's not based on SQLite at all (except for borrowing the SQLite shell implementation) but it looks very much like SQLite, in particular: - It's designed to work as an embedded library, eliminating the network overhead you usually get when talking to a database - Each database is a single file on disk - It ships as an "amalgamation" build - a single gian…

How might one go about using this in a language that’s not supported in the documentation such as golang?

Generally you would need to write bindings for the system. Experimental DuckDB bindings for Go do exist [1], however, they are rather old and might not work anymore.

We also have JDBC support, which might help for languages that know how to use that protocol. ODBC support is not implemented yet, but also planned.

We also have a SQLite-compatible C API [2], that can potentially be used to use an existing SQLite driver that uses the SQLite C API.

[1] https://github.com/marcboeker/go-duckdb

[2] https://github.com/cwida/duckdb/blob/master/tools/sqlite3_ap...

Re: DuckDB – An embeddable SQL database like SQLite, but supports Postgres features

#46
post #9

Earlier quoted context omitted.

That's awesome news, thanks for that!

No problem I was curious as well and hunting it down, this project does seem interesting, I'm a huge fan of database systems like SQLite and H2. There's something wonderful about being able to copy a simple file and share it with other developers. This one seems rather interesting as well.

That’s what made Excel so popular.

Re: DuckDB – An embeddable SQL database like SQLite, but supports Postgres features

#47
I really wish ALL software project / framework / libary could follow the lead here. Instead of your marketing page telling me how world changing awesome tech you have, which really is a consumer marketing strategy. Just do it like DuckDB,

When to use DuckDB ; When to not use DuckDB

Re: DuckDB – An embeddable SQL database like SQLite, but supports Postgres features

#50

Earlier quoted context omitted.

> - Each database is a single file on disk Are these architecture independent? i.e. If I create the database on x86_64 and move it to ARM64; would it work seamlessly?

One of the authors here - portability of the storage is indeed one of our goals. We test that the same file can be loaded everywhere on different systems, including between ARM and x86. I should mention the storage is still very much a work-in-progress. We are actively working on redesigning the storage to add compression and other extra features, meaning the storage format can change and be incompatible between diff…

Couldn't you have used an already existing format for storage, e.g. Apache ORC?
Post reply on HN