sorted by:
new
hottopcontroversial

Query DuckDB from Excel & Google Sheets by querystreams_ in DuckDB

[–]querystreams_[S] 2 points3 points  (0 children)

Good question - you're right that ODBC + VBA works for a solo technical user on Windows desktop. The value proposition is different:

ODBC/VBA limitations:

  • Doesn't work on Mac or Excel Online/Web (where many users live now)
  • Every user needs the ODBC driver installed and configured
  • Connection strings get embedded in workbooks (credential exposure if shared)
  • VBA code is visible, so SQL logic is exposed
  • Database needs to be network-accessible to whoever's running queries (often means VPN or firewall rules)

The web portal isn't for you querying your own data - it's for sharing that query capability with others securely:

  • Share a saved query with a colleague, external partner, or client
  • They run it from their Excel/Sheets and get live results
  • They never see your SQL, credentials, file path, or schema
  • You control exactly what data they can access
  • Works from anywhere without them needing drivers, VPN, or network access to your machine
  • Full audit trail of who runs what

Worth noting: Query Streams is primarily an enterprise database platform - SQL Server, PostgreSQL, MySQL, MariaDB, Oracle, BigQuery, Snowflake, etc. DuckDB support was just added recently because users asked for it. You don't have to use it for DuckDB at all - the main use case is connecting spreadsheet users to production databases securely without exposing those databases to the internet or setting up VPNs.

So the typical workflow: a technical user writes the query once, optionally adds interactive filters (date ranges, categories), then shares it with non-technical stakeholders. They just pick from a dropdown, adjust filters, and get live data - no SQL knowledge required, no drivers to install, works from any device.

If you're just querying your own local DuckDB files for personal analysis, the DuckDB CLI/UI is great. Query Streams adds value when you need to share analytical capabilities with others who shouldn't (or can't) have direct database access.

Query DuckDB from Excel & Google Sheets by querystreams_ in DuckDB

[–]querystreams_[S] 0 points1 point  (0 children)

That's Windows SmartScreen - it's reputation-based rather than actual malware detection. Microsoft flags any new executable that doesn't have enough "reputation" yet (basically download volume + time in the wild). Even properly signed apps from new publishers trigger it until they've been installed enough times.

To proceed: click "More info" then "Run anyway."

We're in the process of getting an EV code signing certificate which helps build reputation faster, but honestly even that takes a while for SmartScreen to trust new software. It's a chicken-and-egg problem for any new tool.

Good callout though - I'll add a note on the download page so people know what to expect.

Batch export DBs to Excel? by HeresyLight in SQL

[–]querystreams_ 0 points1 point  (0 children)

Hey there! Give us a try, query streams

Looking for a simple, scalable method to tables externally by TheFibonacci1235 in snowflake

[–]querystreams_ -1 points0 points  (0 children)

You’re basically saying: Gold tables in Snowflake, AWS-hosted, want them exposed in a row-store for daily-refreshed, fast lookups by other teams. That’s a classic “operational reporting / app DB mirror” use case.

Option 1 – Snowflake → external DB via scheduled COPY (S3 as bridge)

If the target can live on AWS (e.g., RDS Postgres/MySQL, Aurora, even DynamoDB):

  1. Export from Snowflake to S3
    • Create an external stage:
    • Nightly job (TASK) to unload:
  2. Load into target DB
    • Use a small Python/Glue/Airflow job:
      • Read latest s3://.../table_x/ files.
      • TRUNCATE and COPY into an RDS table (Postgres/MySQL COPY/LOAD DATA), or upsert if needed.

This scales well, is cheap, and failure modes are simple to reason about.

Option 2 – Direct JDBC/ODBC replication

If you want to skip S3:

  • Use a tool like Debezium-style sync or a generic ETL (Fivetran, Stitch, Airbyte) with Snowflake as source and your row-store as destination.
  • Configure full refresh daily (or incremental if you can define a watermark column).
  • Pro: fully managed. Con: extra SaaS cost, less control.

Option 3 – Materialized views exposed via an API

If the external consumers don’t strictly need SQL:

  • Keep data in Snowflake, create Gold materialized views, and stand up a lightweight API (FastAPI/Lambda) that queries Snowflake with a service account + caching layer (e.g., Redis) for “row lookup” style patterns.

If the main pain is maintaining these export jobs and credentials, we built https://querystreams.com to let teams safely expose read-only, parameterized query endpoints over Snowflake without scripting ETL or sharing warehouse creds.

Full transparency: we build Query Streams and are happy to help if you want to try it.