Skip to main content

KSML Data Service Config

This document provides a high-level overview of TeaQL Data Services.
It is intended to help users understand what data-service types exist and how they are categorized, without going into configuration or implementation details.


1. What is a Data Service (Conceptual)

In KSML, a Data Service represents an abstract binding between:

  • A storage engine (database or memory)
  • A repository implementation
  • An entity descriptor model

Data services are predefined capabilities, not something users need to configure manually in most cases.

Currently, specify data service in element <root>

<root data_service="sqlite" >


2. Core Classification

KSML data services fall into two main categories:

CategoryDescription
SQL-basedRelational databases with SQL support
Non-SQLIn-memory or metadata-driven repositories

3. SQL-Based Data Services

SQL data services generate:

  • SQL repositories
  • SQL-compatible entity descriptors
  • GraphQL integration (optional)

They differ mainly by database dialect and runtime driver.

Supported SQL Engines

Data Service NameDatabase TypeIdentifier Quote Style
postgresPostgreSQL" (double quote)
mysqlMySQL` (backtick)
oracleOracle"
hanaSAP HANA"
db2IBM DB2"
mssqlMicrosoft SQL Server"
sqlserverMicrosoft SQL Server (alias)"
snowflakeSnowflake"
duckDuckDB"
duckdbDuckDB (alias)"
sqliteSQLite"

4. Non-SQL Data Services

Non-SQL services do not rely on SQL generation.

Data Service NameTypeTypical Usage
memIn-memoryTesting, prototyping, transient data

5. Default Data Service

  • One SQL data service may be designated as the default
  • If not explicitly specified, KSML uses the default service for repository generation
  • Typically, postgres is used as the default reference implementation

6. Aliases & Compatibility

Some data services exist as aliases to improve compatibility:

AliasCanonical Service
sqlservermssql
duckdbduck

Aliases behave identically to their canonical counterparts.


7. Why This Abstraction Exists

The Data Service abstraction allows TeaQL to:

  • Support multiple databases with a single domain model
  • Keep KSML and TeaQL independent from storage specifics
  • Switch or extend backend capabilities without rewriting queries
  • Maintain consistent Q / E semantics across environments

8. One-Sentence Summary

TeaQL Data Services define what kinds of storage backends exist, not how users must configure them.