AlaSQL: a SQL engine that runs inside your JavaScript app

What AlaSQL solves, and for whom

JavaScript applications accumulate data in shapes SQL was designed for: an array of objects with a foreign key, a CSV the user just dropped on the page, a spreadsheet a finance team maintains, a table cached in localStorage or IndexedDB. AlaSQL puts a query engine on top of that data without a server. The README describes the library as an open source SQL database for JavaScript with a focus on query speed and data source flexibility, for both relational tables and schemaless data, running in the browser, Node.js and mobile apps.

The audience is narrow and specific. The README names three groups: fast in-memory SQL processing for BI and ERP applications on fat clients, ETL work where data is imported, manipulated and exported between formats, and applications that must run across major browsers, Node.js and mobile. If your data lives in Postgres and your users share it, AlaSQL is not part of that story. If your data arrives in the browser as JSON and someone needs to group, join and filter it, the library removes the round trip to a backend entirely.

How the engine handles tables, arrays and files

AlaSQL parses SQL text and executes it against in-process data structures. The README shows two distinct entry points. Named tables are created with standard DDL and then queried by name. Arrays are passed as parameters, where a question mark stands in for the data source in the FROM clause. Both paths return plain JavaScript arrays of objects.

The data source flexibility is the real mechanism. A FROM clause can point at an Excel file, a CSV file, a JSON file, a TAB file, IndexedDB, localStorage or a SQLite file, per the README's import/export list. That means the same query text runs over a spreadsheet on disk and over an array in memory. Persistence works the other way: a table's data store is a plain JavaScript property, and the README shows a bulk load assigning `alasql.tables.example1.data` directly instead of issuing thousands of INSERT statements. That assignment is the fastest documented way to get a large array into a table, and it bypasses the parser entirely.

The SQL surface aims at most of SQL-99, with extra syntax for schema-less data and graph networks. That extra syntax is where the project departs from a standard engine, and it is also where portability of your queries ends. The README states plainly that proper use of indexes on your tables is essential for good performance, which is a warning worth reading twice: the engine will not save you from a full scan.

Install AlaSQL and query an array of objects

Installation is a normal package install. The README lists the yarn, npm and global CLI forms. The global install is what puts the `alasql` command on your PATH, and the project's own test script uses it to run `select 1 as Succes` as a smoke test.

npm install alasql
npm install -g alasql

In Node, require the package and pass SQL with a parameter array. The README's array example groups and sums a list of objects, with the `?` placeholder standing for the data.

var alasql = require('alasql');

var data = [
  {a: 1, b: 10},
  {a: 2, b: 20},
  {a: 1, b: 30},
];

var res = alasql('SELECT a, SUM(b) AS b FROM ? GROUP BY a', [data]);
console.log(res);

The result the README documents for that input is `[{a:1,b:40},{a:2,b:20}]`. If you see that, the engine is working and your data reached the query through the parameter path.

For a browser page, the README points at the jsDelivr build and shows a script tag pinned to major version 4.

<script src="https://cdn.jsdelivr.net/npm/alasql@4"></script>

After that script loads, `alasql` is a global and the same query strings work. Note the package's own manifest: `main` is `dist/alasql.fs.js` for Node and `browser` is `dist/alasql.min.js`, so bundlers pick a different file depending on target. If you build for both, verify which artifact landed in each bundle.

Reading a spreadsheet from a query

The Excel path is the feature that distinguishes AlaSQL from a generic SQL parser. The README's example passes an array of SQL strings rather than a single string, which makes the call return a Promise, and the FROM clause points at a file path without an extension.

alasql([
  'SELECT * FROM XLS("./data/mydata") WHERE lastname LIKE "A%" and city = "London" GROUP BY name'
])
  .then(function (res) {
    console.log(res);
  })
  .catch(function (err) {
    console.log('Does the file exist? There was an error:', err);
  });

The README notes that the output depends on the contents of mydata.xls, and it puts the file-existence question in its own error message. That is a fair signal about the failure mode: most problems with this path are path problems, not SQL problems. The README also lists both `.xls` and `.xlsx` among supported import formats. Treat the spreadsheet path as an import step, not a live data source. Nothing in the README suggests the file is watched or re-read.

Where AlaSQL is the wrong tool

The first limitation is concurrency. AlaSQL runs inside one JavaScript process. Two browser tabs, or two Node workers, hold separate databases with separate tables. There is no server, no connection protocol and no locking between them. Any workflow where two users must see the same row at the same time is outside the design.

The second is scale. Everything runs in memory, and the README's own performance note says indexes are essential. A table large enough to strain the browser's memory is a table this library cannot help with, and there is no documented spill-to-disk path for query execution.

The third is SQL coverage. The README claims compliance with most of SQL-99 and links to a wiki page of supported statements. Most is doing real work in that sentence. Window functions, stored procedures, triggers and the vendor-specific extensions you may rely on from another engine are not promised anywhere in the README, and the additional NoSQL and graph syntax means queries you write here may not run elsewhere. The wiki is the only place that answers coverage questions, and the README does not summarize it.

Finally, the project describes itself as unfunded and built on unpaid voluntary work. That is a support-model limitation rather than a technical one, but it matters when you are deciding whether to route a production workflow through it. Recent releases exist and the repository is not archived, so the code is moving; the maintainer bandwidth is the variable.

AlaSQL compared with sql.js and DuckDB

The two names that come up most often alongside AlaSQL are sql.js and DuckDB, and the approaches differ in ways that decide the choice.

sql.js is SQLite compiled to WebAssembly. You get a real SQLite database in the browser, with SQLite's file format, SQLite's SQL dialect and SQLite's constraints. The cost is that you load and manage a database file, and the API is closer to a database driver than to a JavaScript function call. AlaSQL takes the opposite route: it is a JavaScript parser and executor that reads native JavaScript values directly, so an array of objects is a first-class table and an Excel file is a valid FROM target. If your data is already JavaScript objects and you want to avoid a database file, AlaSQL is the shorter path. If you need SQLite compatibility, sql.js is the one that gives it.

DuckDB is a columnar analytical engine, available for Node and the browser through its own bindings. It is built for aggregation over large datasets and will outperform a row-oriented in-memory engine on that workload. It is also a different dependency with a different execution model. AlaSQL's advantage is that it needs nothing but the package itself and accepts the data shapes a JavaScript application already has. For a few thousand rows in a form-driven UI, that difference is the whole decision.

Licence, upgrade cost and what the repository tells you

AlaSQL is MIT licensed, and the LICENSE file sits at the top level of the repository. MIT is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and licence text travel with it. That is the plain reading of the licence text, not legal advice; if you vendor the built file into a product, keep the notice intact.

The practical upgrade cost is the built artifact, not the source. The package publishes `dist/alasql.fs.js` for Node, `dist/alasql.min.js` for the browser and TypeScript declarations at `types/alasql.d.ts`. There is also a `./precompile` export pointing at `dist/precompile/index.js`, which suggests a query precompilation path exists; the README does not explain it, and the repository has an `examples/precompile/` directory if you want to read the code rather than the prose.

Version 4.19.1 was released on 2026-09-07, following 4.19.0 on 2026-08-25 and 4.18.0 on 2026-08-20. The last push to the develop branch was on 2026-09-19. The repository is not archived. CHANGELOG.md and RELEASES.md at the top level are the files to read before bumping a major version, because the README does not document a compatibility policy and does not mention rollback.

Editorial conclusion

Adopt AlaSQL when the data already sits in the browser or in a Node process and you want SQL over it: a fat-client BI or ERP screen, a CSV or Excel import step, a query layer over an array of objects. Do not adopt it as a shared server database, and do not expect it to replace SQLite or a warehouse for large tables. Before committing, verify the SQL subset your queries need against the wiki's supported statements page, and check that the build you ship matches the import path you use (dist/alasql.fs.js for Node, dist/alasql.min.js for the browser).

Frequently asked questions

Official sources

1. AlaSQL/alasql on GitHub
2. License: MIT
3. Project website
4. README
5. Releases