Cómo ejecutar una consulta SQL sobre un archivo local

Carga un archivo CSV, TSV, JSON, NDJSON o Parquet y consúltalo con SQL: la página entrega el archivo a un motor DuckDB que se ejecuta dentro de la pestaña, lo expone como la tabla data y muestra el resultado de tu sentencia SELECT o WITH en una tabla que puedes exportar. El motor es DuckDB-Wasm 1.32.0 dentro de un Web Worker: los bytes del archivo van a ese worker y a ningún otro sitio.

El alcance es deliberadamente estrecho: un archivo a la vez, sentencias de solo lectura y una vista previa de 200 filas como máximo. Con eso se cubren los usos habituales de una página así — revisar un esquema antes de importar un volcado, hacer un GROUP BY sobre un informe exportado o echar un primer vistazo a un Parquet cuando no hay lector de escritorio instalado — sin levantar una base de datos.

Elige un archivo en Archivo de datos local y pulsa Cargar archivo seleccionado. El selector acepta .csv, .tsv, .json, .ndjson, .jsonl, .parquet y .txt, y un archivo .txt se interpreta como CSV separado por comas. Cuando el motor lo ha leído, la línea de estado lo nombra: «orders.csv está listo en la tabla local data. Ejecuta abajo una consulta SELECT.»
Escribe una sentencia contra data en el cuadro, o mantén la predeterminada SELECT * FROM data LIMIT 100. Pulsa Cargar datos de ejemplo para probar la herramienta sin archivo: carga cuatro filas de un CSV pequeño (id, name, team, monthly_events) y una consulta GROUP BY sobre ellas que devuelve tres filas.
Pulsa Ejecutar consulta y la sentencia se ejecuta en el navegador. La tabla de resultados muestra los nombres de columna que devolvió el motor y hasta 200 filas, y la franja superior indica el archivo, el número de columnas y las filas en pantalla: un valor como 200+ significa que el resultado era más largo que la vista previa.
Pulsa Exportar el CSV visible para guardar exactamente las filas en pantalla, con su cabecera, como kivtools-query-results.csv, o Restablecer consulta para recuperar la sentencia predeterminada y vaciar la tabla. El botón de exportación sigue desactivado hasta que una consulta devuelva filas.

Dónde se ejecuta la consulta, qué lee la herramienta y de dónde sale el límite de 200 filas

Formatos, la tabla data y la regla de solo SELECT

CSV y TXT pasan por el lector CSV, TSV por ese mismo lector con tabulador como separador, JSON y NDJSON/JSONL por el lector JSON y Parquet por el lector Parquet, de modo que los tipos de columna se deducen del archivo y no los declaras tú. Todo acaba en una vista llamada data, y cargar otro archivo la sustituye: no hay una segunda tabla ni forma de unir dos archivos.

Solo se aceptan sentencias que empiezan por SELECT o WITH. DROP TABLE data y DELETE FROM data se rechazan antes de llegar al motor, con el mensaje «Por seguridad, Data Lab solo ejecuta consultas SELECT y WITH.» Un punto y coma final suelto no molesta, pero cada pulsación ejecuta una sentencia: SELECT 1; SELECT 2 acaba en un Parser Error, y una extensión no admitida como .xlsx se rechaza con un mensaje que enumera los formatos que sí funcionan.

La vista previa de 200 filas es un límite de pantalla, no de consulta

Lo que escribes se ejecuta como SELECT * FROM (<tu consulta>) AS kivtools_visible_result LIMIT 201, y la página dibuja como mucho 200 de las filas devueltas. Pide SELECT * FROM data sobre un Parquet de 1.000 filas y la línea de estado dirá «200 filas mostradas (limitado a 200)» mientras las métricas cuentan 200+; añade tu propio ORDER BY salary DESC LIMIT 5 y verás cinco filas exactas.

Exportar el CSV visible escribe lo que muestra la tabla —una línea de cabecera más esas mismas filas, hasta 200, con finales de línea CRLF— y no el resultado completo, así que un resultado agrupado de cinco filas exporta cinco líneas de datos. Para más, agrupa o recorta dentro de la sentencia: la vista previa está pensada para leer, no para sacar el archivo entero del navegador.

Qué te dice una consulta que falla

Los mensajes de error vienen del propio motor y se imprimen tal como llegan. Una columna mal escrita produce Binder Error: Referenced column “nope” not found in FROM clause! Candidate bindings: “name”, “monthly_events”; una tabla inexistente produce Catalog Error: Table with name nowhere does not exist!; una sintaxis rota produce un Parser Error con la posición marcada; un Parquet truncado produce Invalid Input Error: No magic bytes found at end of file.

Una sentencia fallida deja en pantalla el resultado anterior y no estropea la sesión: la siguiente Ejecutar consulta funciona con normalidad y el archivo sigue cargado. Como los fallos llegan como texto de mensaje y no como una página rota, puedes corregir la sentencia en el cuadro sin recargar la página ni volver a elegir el archivo.

Velocidad, primera descarga y privacidad

En Chrome, un CSV de 6 MB con 200.000 filas quedó consultable en torno a un cuarto de segundo, y un GROUP BY y una función de ventana sobre él respondieron en tiempos similares; un Parquet de 1.000 filas y 13 columnas necesitó unos segundos para su primera lectura. La primera visita a la página descarga el motor —34 MB de WebAssembly más los módulos de Apache Arrow— antes de que corra la primera consulta, y las visitas posteriores lo arrancan desde la caché del navegador en aproximadamente un segundo.

Los archivos seleccionados se leen dentro de la pestaña: los bytes se registran en el Web Worker que aloja el motor, y ni el archivo, ni la sentencia que escribes, ni las filas del resultado se envían a VoriTools. Con el panel de red del navegador abierto, ejecutar una consulta sobre un archivo cargado no genera ninguna petición. La otra cara es que la herramienta no puede traer un archivo desde una URL, y una pregunta que necesita dos archivos hay que hacerla en dos pasadas.

Consultar CSV, JSON y Parquet con SQL