What this release covers
An honest scope page. If you are deciding whether TableCore fits your work, read this one before the feature pages — it is the list of things it will not do as much as the list of things it will.
What it does
- Query MongoDB with SQL.
SELECTstatements are translated to MongoDBfindandaggregatecommands and run on your server. The generated command is always available to read. - Query MongoDB with MongoDB. The editor also accepts shell syntax
(
db.orders.find(…)) and raw command documents, and works out which one you typed. - Show you the plan. Explain reports the stages, the documents examined per row returned, and whether an index was used.
- Export the query as code.
mongosh, the C# driver, and C# LINQ where a lambda can express the query faithfully. - Browse and edit documents in a type-aware grid, with schema inference, JSON Schema validation rules, index management and index usage statistics.
- Move data: export results, GridFS, backup and restore, collection reshaping, and migration from a relational database.
- Watch the server: live metrics, current operations and
killOp, replica set state and the oplog window, the database profiler, and sharded-cluster views.
Connection profiles keep only non-secret metadata on disk; connection strings and SSH credentials go to the operating system's credential store.
What it deliberately does not do
SQL is read-only. SELECT only. INSERT, UPDATE, DELETE, CREATE,
DROP and every other statement is refused by the parser with Expected SELECT
or a MongoDB command document.
This is a product decision, not a missing feature, and it will not change
casually. The engine translates between two languages with different semantics.
A translation defect in a SELECT shows you the wrong rows, which is bad and
recoverable — you notice, and nothing on the server moved. The same defect in an
UPDATE writes wrong data to a production database, and there is no version of
that which is recoverable.
Read-only SQL is not a read-only application
TableCore can still write, just not through translated SQL: editing a document in the grid, the explorer's create/rename/drop actions, import, restore, reshape and migration all write, and a raw MongoDB command document typed into the editor writes if that is what it says. If you want a connection that cannot write at all, mark it read-only — and for a guarantee rather than a guard, ask your administrator for a read-only MongoDB user.
Also not in this release:
| Not available | Notes |
|---|---|
| macOS and Linux builds | A build path exists; nothing is published. See Installation |
| Signed Windows installers | Builds are unsigned and SmartScreen says so |
| Migration from PostgreSQL, MySQL/MariaDB, SQL Server or Oracle | SQLite is the only shipped source. See Migrating from SQL |
Export to Excel or SQL INSERT statements | See Exporting results |
| Code generation for TypeScript, Python, Java or Go | mongosh, the C# driver and C# LINQ are what exist |
| Profiler diagnostic rules | The profiler shows and groups; it does not yet name findings |
| A MongoDB user and role manager, task scheduler, or data compare | Not built |
| Teams, seats, SSO and shared connections | Enterprise is not purchasable and is shown only as Coming soon |
None of these have dates. When one ships it will appear on its page, and not before.
Which SQL is accepted
The short version: a SELECT with WHERE, GROUP BY, HAVING, ORDER BY,
LIMIT/OFFSET, joins, DISTINCT, common table expressions, window functions
and set operators. The dialect is close to PostgreSQL's SELECT, with TOP,
[bracketed identifiers] and OBJECTID(…) carried over.
A clause or function the engine does not implement produces a diagnostic with a
position in your query. It is never silently treated as a field name, and a
WHERE fragment the engine could not consume is never replaced with an empty
filter — a query that returns everything because the engine dropped your
condition is the failure mode this rule exists to prevent.
SQL support is the full clause-by-clause reference.
How closely the answers match SQL
TableCore's engine is measured against public corpora nobody here wrote. The results are published, including the ones that do not flatter it, because a translation layer that claims to be exact is claiming something no translation layer is.
- Sakila — 282 queries over a sixteen-table schema. Every one must agree; this is a pass/fail gate, not a score.
- Spider — 1,034 questions over twenty unrelated databases. 651 agree, 232 are refused, 111 differ. Most of the refusals are one shape: a comparison against a double-quoted name, which SQL says is a column and which these questions mean as text. The engine used to answer those with no rows and no explanation.
- BIRD Mini-Dev — 348 questions over databases taken from working systems. 268 agree, 46 are refused, 23 differ.
- sqllogictest — 8,884 queries from the SQLite project's own test suite, each declaring the answer it expects. 2,690 agree, 5,775 are refused, 419 differ. Most of the refusals are two shapes the engine does not translate — comma joins and long chains of set operators — which it declines by name rather than answering approximately.
The numbers and what is behind them are on SQL support.
Where the version numbers come from
Releases are versioned Year.Feature.Fix and published on the win-x64-stable
channel. The download page always shows the current one, and the
release archive keeps the older builds with their
checksums.