111–120 of 167 posts
So I tried a simple query in the live demo and it seems that the WHERE clause isn't filtering anything. Am I missing something? SELECT * FROM part WHERE p_size = 7;
Earlier quoted context omitted.
Countless mobile apps use SQLite.
In this case though I'm talking of a COBOL backend very old windows app. We want to move data from COBOL files to a database, we're making our own migration tools/scripts in python (In order to mainly rename weird name table/column names to sanish ones), and we can target any SQL flavour/database we want to insert that data at.. the question is what's the better call here... SQLite seems pretty good enough, at least…
Do note that sqlite itself doesn't have the kindest handling of date/times, you are at the mercy of your data provider (unless you are going native) Especially when timezones are involved.
If it's running on windows machines you could consider Sql Server LocalDB (runs in user mode, i believe you are allowed to distribute as such in an app). But it doesn't sound like that would make sense from what I've read for your case and tech stack.
Sqlite is a good start because even if you are wrong, it should be pretty dang easy to migrate to whatever is right. :)
I was hoping from the title that it aims for postgres SQL compatibility, but I can't find it explicitly mentioned in the docs. This really makes me think I really want something like sqlite://memory which completely disregards speed or even persistence. Instead you could say for example "open an in-memory database that behaves like postgres 9" and run your tests against it. With typical fixtures of 10 or so rows, you…
One of the authors of DuckDB here: we use the PostgreSQL parser, and try to be generally compatible with the syntax used by SQLite, Postgres and MySQL. In some cases those are unfortunately mutually exclusive (e.g. null ordering - we have a PRAGMA to change this system-wide). Making the SQL dialect “as compatible as possible” with these systems is very much one of our goals, and if you find any incompatibilities feel…
I'm not sure whether those are in scope for you but it'd be nice if the docs said "to be implemented" or "out of scope" somewhere ... and my apologies in advance if they do and I somehow missed it.
Earlier quoted context omitted.
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…
Hi, author of the Go bindings here. I've just tested them and they are still working with the latest DuckDB version from master.
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
We should make a list of technology that does this, because I know Clickhouse also has a reasonably detailed page on when to use it and when to not use it and why. Postgres also has a very nice “do and donts” wiki page.
Can we create a view over multiple parquet files?
Earlier quoted context omitted.
In this case though I'm talking of a COBOL backend very old windows app. We want to move data from COBOL files to a database, we're making our own migration tools/scripts in python (In order to mainly rename weird name table/column names to sanish ones), and we can target any SQL flavour/database we want to insert that data at.. the question is what's the better call here... SQLite seems pretty good enough, at least…
SQLite works well for app files. Bentley uses it for all sorts of stuff and I had way fewer corrupt files in their format than Autodesks. :) Do note that sqlite itself doesn't have the kindest handling of date/times, you are at the mercy of your data provider (unless you are going native) Especially when timezones are involved. If it's running on windows machines you could consider Sql Server LocalDB (runs in user mo…
Actually SQL Server was one of the other contendents, but I disregard it due to it not being open source and having some hard caps in the free license (I think it's 10GB)...
But, I didn't knew about SQLserver local db, so we will look into that!
Earlier quoted context omitted.
OLAP databases can/are still Relational databases. The difference is that they’re optimised for different workloads. SQLite/MySQL/Postgres/MSSQL etc are all OLTP databases whose primary operation is based around operations on single (or few) rows. OLAP databases like ClickHouse/DuckDB, Monet, Redshift, etc are optimised for operating on columns and performing operations like bulk aggregations, group-bys, pivots, etc…
I gather that there may be some differences in functionality offered, but that it’s probably not much. So I presume performance is the biggest area of difference. In that regard: how big are the differences in performance for each category’s representative workloads?
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…
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…
Couldn't you have used an already existing format for storage, e.g. Apache ORC?