Comment by delaminator
3 days ago
From my perspective, everything's DuckDB.
Single file per database, Multiple ingestion formats, full text search, S3 support, Parquet file support, columnar storage. fully typed.
WASM version for full SQL in JavaScript.
This is a funny thread to me because my frustration is at the intersection of your comments: I keep wanting sqlite for writes (and lookups) and duckdb for reads. Are you aware of anything that works like this?
DuckDB can read/write SQLite files via extension. So you can do that now with DuckDB as is.
https://duckdb.org/docs/stable/core_extensions/sqlite
My understanding is that this is still too slow for quick inserts, because duckdb (like all columnar stores) is designed for batches.
7 replies →
I think you could build an ETL-ish workflow where you use SQLite for OLTP and DuckDB for OLAP, but I suppose it's very workload dependent, there are several tradeoffs here.
Right. This is what I want, but transparently to the client. It seems fairly straightforward, but I keep looking for an existing implementation of it and haven't found one yet.
very interesting. whats the vector indexing story like in duckdb these days?
also are there sqlite-duckdb sync engines or is that an oxymoron
https://duckdb.org/docs/stable/core_extensions/vss
It's not bad if you need something quick. I haven't had a large need of ANN in duckdb since it's doing more analytical/exploratory needs, but it's definitely there if you need it.