Documentation
The product help, one section per page
This documentation mirrors the in-app Help of Commercient Data Lake \ Data Hub as published in the dlake-cli repository. The live copy inside your console and dlake guide help are always current; this mirror was last synced from a source changed 19 Sept 2026.
Browse by what you want to do
Start here4 sections
What you get, how to create a Data Lake, what the landing page tells you, and how to drive it all from a terminal.
Bring data in8 sections
Connect the systems you already run, or load files, and the data lands in your own SQL Server database.
Shape it10 sections
Build tables, views, procedures and indexes with a schema builder, a SQL editor and a data browser.
Serve it9 sections
Publish exactly the tables you choose as REST and GraphQL APIs, to apps and to AI agents.
Govern it9 sections
Decide who sees which rows and fields, and keep a full record of who did what.
Remember it2 sections
See how any row looked at any point in time, and track what changed.
Extend it2 sections
Link object storage, query files as if they were tables, and get told when something needs attention.
All sections in reading order
Browse the complete documentation for Commercient Data Lake \ Data Hub. Follow the sections below in order, or search to jump straight to what you need.
- Getting StartedWhat every tenant gets on day one: a managed SQL Server database, a schema builder, a data browser, a SQL editor and a ready-made data API.
- Registering a New Data LakeCreate your own Data Lake from the command line: sign up, click one emailed link, and the platform provisions and seeds it for you.
- DashboardThe landing page: whether syncs are healthy, how fresh the data is, how many rows moved, what needs attention and how much storage you use.
- TablesCreate and manage tables: columns, keys, defaults, and the per-table features you can switch on. The platform’s own tables stay protected.
- ViewsStandard SQL views over your tables, publishable through the data API exactly like tables once you give them an addressable key.
- Stored ProceduresWrite stored procedures for work that must happen in one transaction, then publish them to the API and to AI agents as named tools.
- TriggersYour own triggers on your tables, checked before they are created. The platform’s own triggers are marked and protected.
- IndexesAdd or drop nonclustered indexes to make queries faster. Names and columns are checked against the database catalogue.
- Full-Text SearchWord and phrase search over text columns using SQL Server full-text indexes. Create the catalogue once, then choose the columns to index.
- FunctionsScalar and table-valued functions in your schema, with the same protections as tables, views and procedures.
- SchemasSchemas are namespaces for your database objects. List them, create one, drop an empty one, and see which one you are working in.
- Security & Access ControlWho can do what: three roles, permissions granted one by one, a second factor for sensitive actions, and the same rules enforced by the API.
- Data BrowserRead your data in the browser with paging and sorting. Row rules and key limits apply, so you see only what you are allowed to see.
- SQL EditorRun read-only T-SQL, export the whole result to CSV or Parquet, or save it into a new table. Admin access and a second factor required.
- Ask Your Data (natural-language query)Ask a question in plain English and get the answer, the query behind it, and a short explanation you can open in the editor.
- Data Ingestion (file → table sync)Load a CSV, Parquet or XML file into a table and keep it in sync, either by uploading in the console or by calling the API.
- Documents (upload, search, retrieval)A document store for PDFs, images and text. Upload once, then search and retrieve from the API, from an AI agent and from the CLI.
- KB Semantic Search (AI corpus)Meaning-based search over a synced knowledge base, separate from the document store. Needs SQL Server 2025 and an embeddings provider.
- Import (Connectors)Pull data in from a system you already run, or let it push into your tables. Eight connectors ship today, with scheduling and verification.
- DAB & API KeysThe engine that serves your REST and GraphQL API, and the keys that reach it: choose what to expose, limit each key, restart to publish.
- Key Usage (who is calling your API)Which of your API keys are actually being used, how heavily, whether their calls succeed, and where they are calling from.
- Resource Usage (what your queries cost)What those API calls cost on the database server: the time and reads they use, and which queries account for most of it.
- Stored Procedures as MCP ToolsPublish a stored procedure to AI agents under its own name, so an agent calls a clear business action instead of a generic tool.
- Admin Control Plane (MCP)A second, separate AI connection that configures the platform and never touches your table data. Set-up work, not data work.
- CRMPro (forward sync)The sync that pushes your ERP data out to your CRM or e-commerce platform, and how to run and troubleshoot it.
- TxDownloaderPro (writeback sync)The return leg: changes made in the CRM travel back to the source system, with a full record of every attempt.
- Normal Sync (source → clone tables)The on-premises agent that copies changed rows out of your SQL Server database into the lake. It runs first in the chain.
- ODBC Sync (non-SQL-Server sources)For sources that are not SQL Server: an agent reads them over ODBC and stages the data so Normal Sync can take it from there.
- Commercient Sync Agent (the on-premises agent)The Windows agent on your own server that actually reads your ERP. Nothing syncs until it is installed, configured and connecting.
- Generic API Sync (API sources)When the source is an API rather than a database, this teaches the sync agent which endpoints to call.
- Command-Line Interface (dlake)dlake is the terminal client for your tenant: sign in with an API key and script everything the console can do.
- Row-Level SecurityRules inside the database that decide which rows each caller may see, applied on every read, whoever is asking.
- Change TrackingAsk what changed since last time. Per-table change tracking reports the rows inserted, updated and deleted since a version.
- Time Travel (temporal history)Keep every version of every row automatically, so you can read your data exactly as it looked at any moment in the past.
- Concurrency ProtectionStop two people overwriting each other’s edits, and turn deletes into reversible soft deletes, enforced by the database itself.
- Audit StampingEvery row records who created and last changed it, and when, stamped by the database rather than trusted from the caller.
- Triggers and the Data APIWhy switching on a table feature can stop that table’s API writes until you restart the data API engine.
- Events (SSE, Polling, Webhooks)Find out when rows change: poll for changes, stream them live, or have them delivered to a URL you own.
- WebhooksSend your row changes to a URL you own, signed and retried, so other systems react instead of asking again and again.
- Inbound Webhooks (receiving events)The other direction: let an outside system post events to you, and have them land in your tables.
- Data QualityRules that watch a table and warn you when a feed breaks, a column fills with nulls, or the row count swings unexpectedly.
- Object Storage (S3)Link S3 buckets to browse and move files, export tables straight into a bucket, and query parquet files as if they were tables.
- Audit LogsA searchable record of every schema and SQL operation: who did it, what they ran, and whether it succeeded.
- NotificationsSchema changes, engine deploys, failed operations and platform notices, delivered to each user inside the console.