> What are you guys using it for?

Transparent queries on server/browser in identical sql.

If you play all the tricks Google's Capacitor does to the data layout, you can shove ~2-3 million rows to a browser based query engine in 16-20Mb with duckdb-wasm. We can scale it up to ~1Gb with HTTP range queries, with cache-control.

Then we use Jev to write SQL queries over it in 1-2s, whenever someone has a followup question. Getting Jev to write SQL takes a bit of prep, but my co-founder wrote a paper about clairvoyant query execution a few years ago [1].

I could have 3000 users logged into the same application, but all of them would be bringing their own CPU to run duckdb. My compute scaling problems for my data cube is a solved problem with this approach.

[1] - https://dl.acm.org/doi/10.14778/2733004.2733064

do you have not-big big data* that individuals or sub-teams/groups use? Lots of companies have centralized data <things> (bases, warehouses, lakes, swamps, etc) and runtime security is a challenging issue (i.e row-based security). If your audience measures their data in GB or MB, DuckDB can be an excellent way to punt on the security challenges and just provide them with ALL their data - maybe even locally - while they still get first-class DB tooling and performance (or even better than classic client-server). Example - old way: build a bunch of dimensions and facts for marketing, manage their access and permissions, produce reports, make sure you don't leak data they shouldn't see. new way: write (explore using AI) some extract/transforms from your SoT & create parquet files, use duckdb to serve that up to an individual or group's reporting solution or adhoc usage. IME that one-time investment is not that big and replaces a lifetime of scaling & access issues, or worrying about someone writing a query that doesn't join with the user table correctly!

* IME most companies don't actually have BIG data, but are talking about (at most) a few TB, which DuckDB is fine with.

I've used it for data migration combined with Jupyter Notebook.

While I'm fully aware of DataFrame, I am more familiar with SQL. So I used Python scripts in Jupyter to load Excel sheets into DuckDB, and then run queries in DuckDB. Eventually I export the data back to Excel or SQL Server.

Not the most efficient way to do this I know, but it works for me.

It's a really good daily multitool for data. E.g. I often have to do work on multiple csv and excel files, joins and filters etc. I hate excel but am fine with SQL. With a duckdb session in dbeaver, I can literally select, project, and join the files on disk as if they were tables. It saves so much time and fuss

For bigger integrations I use it as a trino alternative. If I have to combine multiple data sources I'll walk down the DB buffet and fill my local duckdb with datasets from each source with pandas.read_sql, and then do the joins locally, and publish or push the data back out.

Use it for viewing csv and json files. Also, converting between formats can be a one liner.

I recently used it for a Rust profiler which writes Parquet files, so DuckDB then gives an easy SQL interface for things like summarization, analysis, and joins across runs.

You can use it to connect every single data source that's around your company and then use it as a federation engine (e.g. spreadsheets!)

I’ve got a number of Claude scheduled workflows that pull data from our warehouse to make a dashboard. I have it add an embedded DuckDB to the artifact and load all data into there. Makes it easy to diff and extend the dashboard.

Embedded into .Net monolith app to replicate MSSQL data into it and do queries around this data, because MSSQL is SLOW on those queries =)

Write a log processing/aggregation tool!

we get these hundreds of thousands of lines cost exports on a daily basis from our cloud provider

we process it 'daily' convert it from csv to parquet with a little post-processing for attribution, and have a small duckdb-powered dashboard/wrapper for reporting and dynamic queries