TableCore

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. SELECT statements are translated to MongoDB find and aggregate commands 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 availableNotes
macOS and Linux buildsA build path exists; nothing is published. See Installation
Signed Windows installersBuilds are unsigned and SmartScreen says so
Migration from PostgreSQL, MySQL/MariaDB, SQL Server or OracleSQLite is the only shipped source. See Migrating from SQL
Export to Excel or SQL INSERT statementsSee Exporting results
Code generation for TypeScript, Python, Java or Gomongosh, the C# driver and C# LINQ are what exist
Profiler diagnostic rulesThe profiler shows and groups; it does not yet name findings
A MongoDB user and role manager, task scheduler, or data compareNot built
Teams, seats, SSO and shared connectionsEnterprise 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.