Flagship Product · Early Access

MTS

A NewSQL database for transactional, analytical, and AI-era data.

Distributed ACID. Cassandra and DynamoDB-compatible adoption paths. Memory-resident hot state, hybrid search, native vectors, real-time rollups, PITR, and zero-ETL analytics — under one operational contract.

Request access View proof

NewSQLElastic scaleCassandra + DynamoDB pathsGlobal ACIDHybrid queriesMemory-residentZero-ETL

Why MTS Now

Choose one database before vector DB, Redis, search, and CDC split the stack.

Modern applications are transactional, document-shaped, lexical, semantic, analytical, and real-time. MTS brings vector retrieval, full-text search, hot state, rollups, recovery, and analytics into one authoritative database contract before teams accumulate replatforming debt.

Postgres default

Old path

Start familiar, then add replicas, partitioning, sharding, JSONB indexes, pgvector, Redis, CDC, search, and a warehouse.

MTS path

Start with elastic execution, hybrid query planning, memory residency, recovery, and zero-ETL analytics in the database contract.

Vector DB sidecar

Old path

Move embeddings into a separate vector database, then reconcile freshness, tenant filters, permissions, and ranking with operational records.

MTS path

Keep vector retrieval as a native access path that composes with structured filters, documents, full-text search, and database visibility.

Cassandra default

Old path

Model every product view as another table, then own write fanout, backfills, repair, search, analytics, and narrow LWT limits.

MTS path

Keep a familiar CQL entry point while adding maintained access paths, global ACID, native search, rollups, and diagnostics.

DynamoDB default

Old path

Use a common AWS SDK surface, then move richer queryability, recovery, analytics, and search into surrounding systems.

MTS path

Use endpoint override patterns for supported workloads while gaining a stronger operational and analytical foundation underneath.

Redis / warehouse sidecars

Old path

Split hot state and analytics into separate systems with separate TTL, freshness, recovery, and correctness rules.

MTS path

Keep sessions, counters, feeds, rollups, search, vectors, and analytical views under one authoritative database lifecycle.

Developer Walkthrough

Build the app as requirements arrive.

Start with a normal operational schema. Add documents, full-text, vectors, and hybrid search as product requirements arrive. When production load grows, scale horizontally and add analytics without changing the database contract.

One appOne database contractNo extra ETL layer

01 / Model

Start with the application schema.

Requirement

The first release needs tenant-scoped support cases, status changes, and transactional ownership.

MTS move

Create the operational table once. The same schema can later gain richer access paths, documents, vectors, and rollups.

Stack avoided

No table-per-feature rewrite.

RowsTenant scopeACID

CREATE TABLE app.support_cases (
  tenant_id text,
  case_id uuid,
  title text,
  body text,
  status text,
  priority text,
  created_at timestamp,
  PRIMARY KEY ((tenant_id), case_id)
);

01 / 07

Product Pillars

One database contract. Familiar entry points.

MTS keeps CQL and DynamoDB-style adoption paths while moving hot state, search, vectors, analytics, recovery, and query advice into the authoritative database.

The core product contract: one authoritative database for structured filters, ordered feeds, documents, text, vectors, hot state, rollups, transactions, analytics, and recovery.

Flexible Data Model

Operational records, structured fields, documents, collections, and vectors.

Query + Retrieval

Scalar, document, full-text, vector, hybrid, and explainable planning.

Transactions + Correctness

Explicit transactions and visible freshness choices.

Analytics

Analytical views without making CDC own correctness.

Recovery + Operations

PITR, online evolution, and fail-closed advice.

Memory + Tail Latency

Hot-path state under database semantics.

Native MTS Capabilities

The core product contract: one authoritative database for structured filters, ordered feeds, documents, text, vectors, hot state, rollups, transactions, analytics, and recovery.

Wide-Column Operational Model

Data Model / DBA + Developer

Start from familiar partitioned operational data for tenants, time-series, events, sessions, and high-throughput application state.

Use Case: Move CQL-shaped workloads to MTS while gaining a stronger database contract underneath.
How To Use: CREATE TABLE app.events ( tenant_id text, bucket int, event_id bigint, payload text, PRIMARY KEY ((tenant_id, bucket), event_id) );
Impact: Teams can start from familiar operational modeling without making table-per-query design the ceiling of the system.

Flexible Schema and Documents

Data Model / DBA + Developer

Evolve structured fields, document attributes, maps, collections, and typed document paths without forcing every product attribute into rigid DDL.

Use Case: Model stable business fields as columns while keeping fast-changing customer, product, account, or device metadata in document values.
How To Use: ALTER TABLE app.customers ADD COLUMN lifecycle_stage text; CREATE ACCESS PATH customers_by_lifecycle_stage ON app.customers (tenant_id, lifecycle_stage, created_at DESC) TYPE ORDERED_COMPOSITE;
Impact: Schema evolution and query evolution become database-managed workflows instead of table-routing and backfill projects.

Native Vector Type

Data Model / Developer + AI

Keep embeddings close to operational rows so semantic retrieval can filter against current application context.

Use Case: Build AI search, recommendations, similarity lookup, and retrieval-augmented application flows.
How To Use: CREATE TABLE app.products ( id int PRIMARY KEY, status text, embedding vector<float, 768> ); CREATE ACCESS PATH products_embedding ON app.products (embedding) TYPE VECTOR WITH DISTANCE cosine;
Impact: Semantic retrieval can use current operational context without making a detached vector database the source of truth.

Maintained Access Paths and Rollups

Data Model / DBA + Developer

Use access paths and exact rollups as durable database objects, not application-side caches or denormalized repair jobs.

Use Case: Add ordered feeds, active subsets, common projections, and operational aggregates without creating another source of truth.
How To Use: CREATE ROLLUP case_counts_by_tier ON app.support_cases DIMENSIONS ( tenant_id, DOC_GET_TEXT(profile, '$.account.tier'), status, TIME_BUCKET(created_at, '1h') ) MEASURES (count(*));
Impact: Feeds, projections, and aggregates become maintained database state instead of custom synchronization code.

High-Throughput I/O

Data Access / DBA + Developer

Serve low-latency operational reads and writes while keeping hot work visible and isolatable.

Use Case: Handle mixed read, write, access-path, and maintenance pressure without turning p95/p99 latency into an afterthought.
How To Use: INSERT INTO app.events (tenant_id, bucket, event_id, payload) VALUES ('t1', 202605, 1001, 'checkout'); SELECT * FROM app.events WHERE tenant_id='t1' AND bucket=202605;
Impact: Tail latency becomes part of the database architecture instead of only an operations problem.

Scalar Index Paths

Query + Retrieval / DBA + Developer

Declare scalar equality, range, ordered composite, partial, and covering access paths for bounded lookup beyond primary-key-only reads.

Use Case: Support status filters, time ranges, tenant feeds, active subsets, operational lookup, and common projections.
How To Use: CREATE ACCESS PATH open_orders_by_customer ON app.orders (tenant_id, customer_id, created_at DESC) TYPE PARTIAL_ORDERED WHERE status = 'open';
Impact: Applications can add queryability without encoding every product view as another base table.

Hybrid Search

Query + Retrieval / Developer + AI

Combine tenant scope, structured filters, document predicates, full-text relevance, vector similarity, time ranges, and ranking.

Use Case: Build support search, product discovery, fraud search, and RAG flows that need lexical and semantic retrieval over current application context.
How To Use: CREATE ACCESS PATH support_case_hybrid ON app.support_cases TYPE HYBRID USING ( tenant_id, status, DOC_GET_TEXT(profile, '$.account.tier'), FULLTEXT(title, body), VECTOR(embedding) );
Impact: Search and retrieval stay tied to authoritative rows instead of being reconciled across external engines.

Global ACID Transactions

Transactions + Correctness / DBA + Developer

Use explicit session transactions for supported multi-row and multi-tablet workflows with durable commit decisions and serializable validation.

Use Case: Protect transfers, account changes, entitlements, workflow state, and ledger events where conditional writes are not enough.
How To Use: BEGIN TRANSACTION; UPDATE app.accounts SET balance = balance - 100 WHERE tenant_id = ? AND account_id = ?; UPDATE app.accounts SET balance = balance + 100 WHERE tenant_id = ? AND account_id = ?; COMMIT;
Impact: Correctness becomes an explicit database contract instead of application-side coordination around narrow conditional updates.

Native Full-Text Search

Query + Retrieval / Developer

Use substring and full-text access paths for ranked lexical retrieval with analyzers and field weighting.

Use Case: Support product search, support-case search, operational lookup, highlights, and facets without splitting text state into another system.
How To Use: CREATE ACCESS PATH articles_text ON app.articles (title, body) TYPE FULLTEXT WITH ANALYZER standard_v1 FIELD WEIGHTS (title = 2.0, body = 1.0);
Impact: Teams can build richer application search while keeping row verification and database visibility in the contract.

Explainable Query Planning

Query + Retrieval / DBA + Developer

Use EXPLAIN and ADVISE to show the access path, pushed predicates, bounded work, verification, and missing DDL.

Use Case: Help teams understand why a query is safe, why it is refused, or what access path should be declared next.
How To Use: EXPLAIN SELECT order_id, total FROM app.orders WHERE tenant_id = ? AND customer_id = ? AND status = 'open' ORDER BY created_at DESC LIMIT 50;
Impact: The database can expand query power while fail-closed behavior keeps operational behavior predictable.

Fresh, Stable, and FOLLOWING Reads

Transactions + Correctness / DBA + Developer

Expose read modes for latest owner-visible state, checkpointed scale, and close-following reads with safety boundaries.

Use Case: Let application teams choose the right freshness contract for user-facing updates, reporting, AI context refresh, and read scale.
How To Use: -- Fresh path: read the latest owner-visible state. SELECT * FROM app.orders WHERE order_id = 101; -- Stable path: query a consistent analytical boundary. SELECT customer_id, sum(total) FROM app.orders_analytics GROUP BY customer_id;
Impact: Freshness becomes a product contract instead of accidental replica-lag behavior.

Database-Native Analytical Views

Data Analytics / Data Analytics

Produce versioned analytical views and query metadata from the same authoritative database state used by operational reads and writes.

Use Case: Serve dashboards, reporting, time-window analysis, and AI context refresh without making an external copy own correctness.
How To Use: SELECT TIME_BUCKET(created_at, '1h') AS hour, event_type, SUM(amount) AS revenue FROM app.events_analytics WHERE tenant_id = ? GROUP BY hour, event_type;
Impact: Analytics can move into the database lifecycle while preserving explicit freshness and coverage boundaries.

Zero-ETL Analytics

Data Analytics / Data Analytics

Make operational data analytically readable inside the MTS lifecycle instead of requiring a CDC pipeline or warehouse copy for core analytics.

Use Case: Feed dashboards, product intelligence, recent-history analysis, and AI context refresh from database-produced analytical boundaries.
How To Use: SELECT TIME_BUCKET(created_at, '1h') AS hour, event_type, SUM(amount) AS revenue FROM app.events WHERE tenant_id = ? GROUP BY hour, event_type;
Impact: Teams reduce ETL lag and copy drift while keeping broad warehouse-replacement claims scoped to supported analytical paths.

Granular Point-in-Time Recovery

DBA Operations / DBA

Restore a database, keyspace, table, or scoped target to a precise historical boundary as a new validated target.

Use Case: Recover from bad deploys, accidental deletes, bad batches, schema incidents, and audit requests without destructive in-place rewind.
How To Use: RESTORE TABLE app.orders TO TIMESTAMP '2026-05-01T12:00:00Z' INTO app_restore.orders_validate;
Impact: Recovery becomes a database-native workflow with validation before serving.

Online Index and View Builds

DBA Operations / DBA + Developer

Build and catch up access paths, derived structures, and rollups while production data keeps changing.

Use Case: Evolve queryability after schema or product changes without making application teams own every backfill.
How To Use: CREATE ACCESS PATH orders_feed_covering ON app.orders (tenant_id, status, created_at DESC) TYPE ORDERED_COMPOSITE INCLUDE (order_id, total, currency, customer_id);
Impact: Queryability evolves through database-managed build, catch-up, visibility, and EXPLAIN state.

Typed Refusals and Advice

DBA Operations / DBA + Developer

Fail closed when a query, schema change, restore, or analytical view cannot be proven safe, then return actionable advice.

Use Case: Prevent silent query drift, stale projections, unsafe scans, broken rollups, and destructive DDL surprises.
How To Use: ADVISE ACCESS PATH FOR SELECT order_id, total FROM app.orders WHERE tenant_id = ? AND customer_id = ? AND status = 'open' ORDER BY created_at DESC LIMIT 50;
Impact: Operators see why the database made a decision before that decision becomes an incident.

Memory-Resident Operational Tier

Performance Architecture / DBA + Developer

Keep hot rows, sessions, counters, rate-limit windows, feeds, access paths, vectors, and rollups memory-resident under database-managed policy.

Use Case: Serve latency-sensitive hot state without splitting authoritative truth into Redis or another cache tier.
How To Use: ALTER TABLE app.sessions SET RESIDENCY = MEMORY_FIRST, MEMORY_RESIDENCY_TTL = '10 minutes', MAX_MEMORY = '64 GB';
Impact: A memory miss becomes a latency event, not a correctness event caused by cache drift.

Performance Engine Evidence

Performance Architecture / DBA + Developer

Keep performance claims attached to workload evidence for reads, writes, scans, mixed traffic, and vector serving.

Use Case: Evaluate migrations where compatibility cannot come at the cost of read/write throughput or latency.
How To Use: SELECT * FROM app.kv WHERE pk='u:1001'; INSERT INTO app.kv (pk, ck, value) VALUES ('u:1001', 1, 'v1'); -- compare p50, p95, throughput, and benchmark scope below
Impact: The page can sound strong while showing exactly where the proof comes from.

Beyond Compatibility

The adoption layer: familiar Cassandra and DynamoDB entry points that lead into a stronger operational, analytical, recovery, and queryability foundation.

Driver-Ready Cassandra Compatibility

Cassandra Path / DBA + Developer

Point existing Cassandra 3.11/4.x drivers at supported workloads, then move beyond table-per-query modeling.

Use Case: Migrate services without rewriting the application driver layer first, then add native access paths, transactions, analytics, and recovery under the same product.
How To Use: const client = new Client({ contactPoints: ['mts-db.local'], localDataCenter: 'dc1', keyspace: 'app' }); await client.execute('SELECT * FROM users WHERE user_id=?', [userId], { prepare: true });
Impact: CQL becomes the entry point, not the ceiling of the database model.

Supported DynamoDB SDK Paths

DynamoDB Path / Developer

Run supported DynamoDB-style item, query, pagination, batch, transaction, backup, and restore workflows through endpoint override patterns.

Use Case: Bring AWS SDK-shaped services into the same data platform as CQL, analytics, search, vectors, and recovery.
How To Use: client = boto3.client( "dynamodb", endpoint_url="https://mts.example.com", region_name="us-east-1", ) client.query( TableName="Sessions", KeyConditionExpression="tenant_id = :tenant", )
Impact: DynamoDB compatibility becomes an adoption path without implying full AWS service parity.

Pgvector Evaluation Path

Postgres / Vector Path / Developer + AI

Use the pgvector-facing benchmark story as evaluated vector evidence, not as a broad PostgreSQL replacement claim.

Use Case: Compare AI retrieval serving and query-ready behavior against familiar pgvector baselines while keeping operational context in view.
How To Use: SELECT id FROM app.products ORDER BY embedding <-> '[0.0, 0.0]' LIMIT 10;
Impact: Vector proof stays understandable to AI teams while remaining scoped to the evaluated surface.

Postgres Default Escape Hatch

Postgres / Vector Path / Developer + Architect

Choose MTS before a Postgres default turns into replicas, shards, Redis, search, pgvector, CDC, queues, a warehouse, and repair code.

Use Case: Start products with elastic scale, hybrid search, analytical isolation, hot state, scoped recovery, and query advice in the database contract.
How To Use: CREATE TABLE app.customers ( tenant_id text, customer_id uuid, profile document, embedding vector<float, 768>, PRIMARY KEY ((tenant_id), customer_id) );
Impact: Teams can design for future scale and retrieval needs at project creation instead of replatforming after success.

Fast Compute Elasticity

Scalability / DBA

Scale serving capacity around workload pressure without making every capacity change a data-rebalancing event.

Use Case: Handle tenant growth, seasonal load, and sudden traffic spikes while scale-out follows provisioning, health checks, and tablet assignment.
How To Use: kubectl scale deployment/mts-db-query --replicas=16; kubectl scale deployment/mts-db-analytics --replicas=4;
Impact: Capacity can become useful without waiting for terabytes of dataset transfer.

Benchmarked Read/Write Evidence

Performance / DBA + Developer

Compatibility is paired with benchmark evidence for reads, writes, mixed traffic, scans, latency, and vector serving.

Use Case: Evaluate migrations where read performance cannot become the downside of compatibility.
How To Use: SELECT * FROM app.kv WHERE pk='u:1001'; INSERT INTO app.kv (pk, ck, value) VALUES ('u:1001', 1, 'v1'); -- compare p50, p95, throughput, and wins below
Impact: Read and write claims stay attached to measurable workload evidence.

CQL, Plus Transactions

CQL Plus / Developer

Keep familiar CQL-style access while adding supported explicit transaction flows where correctness requires them.

Use Case: Modernize Cassandra-style applications that need targeted transactional guarantees.
How To Use: BEGIN TRANSACTION; INSERT INTO app.entitlements (user_id, plan) VALUES ('u1', 'pro'); UPDATE app.accounts SET state = 'active' WHERE account_id = 'a1'; COMMIT;
Impact: A migration can add correctness without abandoning the entry interface.

Zero-ETL Analytics Path

Analytics / Data Analytics

Keep analytical access inside the database lifecycle through produced views and visibility boundaries instead of defaulting to copy-pipeline sprawl.

Use Case: Support operational reporting, AI context refresh, and recent-history analysis without waiting on batch movement.
How To Use: SELECT customerid, equipmentid, sum(packetcount) FROM app.metrics WHERE customerid='c1' GROUP BY customerid, equipmentid;
Impact: The architecture reduces pipeline pressure while keeping broad analytics claims scoped to supported paths.

Beyond Table-Per-Query

Query Power / DBA + Developer

Move beyond narrow Cassandra modeling with bounded scalar, range, ordered, document, text, vector, hybrid, and rollup paths.

Use Case: Modernize workloads that outgrow key-value access or denormalized table-per-query designs.
How To Use: ADVISE ACCESS PATH FOR SELECT id FROM app.products WHERE status='active' AND MATCH(title, 'wifi') ORDER BY embedding ANN OF [0.0, 0.0] LIMIT 10;
Impact: Compatibility becomes the starting point, not the ceiling of the database contract.

Elastic Architecture

Elastic execution without customer-owned sharding.

MTS abstracts routing, capacity assignment, visibility boundaries, memory residency, analytical isolation, and recovery so application teams do not own shard maps, cache truth, replica lag, or CDC correctness.

Elastic Execution

Add serving capacity without turning scale-out into a customer-managed data movement project.

Scale-out follows provisioning, health checks, routing, and tablet work assignment instead of copying the dataset before capacity is useful.

Memory-Resident Operational Tier

Keep sessions, counters, feeds, access paths, vectors, and rollups hot without splitting truth into Redis.

Memory eviction affects latency, not correctness. Data TTL, memory residency, and recovery retention stay separate database policies.

Granular Recovery

Restore a database, keyspace, table, or scoped target to a precise historical boundary.

PITR creates a validated recovery target without destructive in-place rewind of the current source.

Workload-Isolated Analytics

Serve analytical views inside the database lifecycle without stealing resources from latency-sensitive writes.

Current, recent, historical, and rollup-covered analysis use explicit visibility and coverage metadata.

Benchmark Dossier

Proof with the scorecard visible.

Two shareable reports carry the performance story: an operational CQL evidence summary and a vector benchmark scorecard. The workload, baseline, date, and scope stay attached to the claim.

CQL benchmark evidence

Selected CQL workloads show strong operational wins.

MTS is compared against local 3-node Cassandra and ScyllaDB controls. The summary below keeps individual workload numbers, baselines, and scope visible instead of compressing an in-progress closeout into a single marketing claim.

CQL evidence summary / Apr 2, 2026

suite rows tracked

3-way

local comparison

highlighted wins

Apr 2026

evidence summary

0.74 ms

LWT p50

55,365 ops/s

async write throughput

357,650 rows/s

token range scan

Selected workload evidence+

WorkloadBaselineMTSOutcome

Workload

LWT latency

Baseline

Cassandra 2.16 ms / ScyllaDB 21.49 ms

MTS

0.74 ms p50

Outcome

selected win

Workload

Mixed workload throughput

Baseline

Cassandra 4,034 / ScyllaDB 6,556 ops/s

MTS

7,824 ops/s

Outcome

selected win

Workload

Concurrent read throughput

Baseline

Cassandra 5,093 / ScyllaDB 5,303 ops/s

MTS

10,781 ops/s

Outcome

selected win

Workload

Async write throughput

Baseline

Cassandra 13,680 / ScyllaDB 43,240 ops/s

MTS

55,365 ops/s

Outcome

selected win

Workload

Token range scan

Baseline

Cassandra 170,950 / ScyllaDB 239,350 rows/s

MTS

357,650 rows/s

Outcome

selected win

Workload

Point-read latency

Baseline

Cassandra 0.21 ms / ScyllaDB 0.09 ms

MTS

0.08 ms p50

Outcome

tie under latency rule

Tie rule: within 5% of the best primary metric, or within 0.02 ms for latency rows. Comparison covers local 3-node Cassandra, local 3-node ScyllaDB, and local 3-node MTS. This summary presents selected source-backed evidence; the final full-suite closeout remains governed by the in-repo benchmark source of truth.

Vector benchmark results

15 of 15 evaluated vector workloads won across pgvector and Cassandra-compatible paths.

The vector report covers scored query serving and time-to-query-ready workloads: 5 pgvector-surface wins and 10 Cassandra-compatible wins within the agreed benchmark scope.

Vector scorecard / Apr 20, 2026

15/15

evaluated workloads won

5/5

pgvector wins

10/10

Cassandra-compatible wins

>9.4x

query-ready rate

7,037.8 qps

pgvector top-1 throughput

0.190 ms

pgvector top-1 p50

587.516 rows/s

MTS query-ready vs Cassandra

Selected workload evidence+

WorkloadBaselineMTSOutcome

Workload

pgvector large top-1 throughput

Baseline

4,979.9 qps

MTS

7,037.8 qps

Outcome

+41.3%

Workload

pgvector large top-1 latency

Baseline

0.270 / 0.314 / 0.397 ms

MTS

0.190 / 0.239 / 0.303 ms

Outcome

p50/p95/p99 lower

Workload

pgvector query-ready rate

Baseline

232.513 rows/s

MTS

773.790 rows/s

Outcome

>3.3x

Workload

Cassandra top-1 vector p95

Baseline

6.033 ms

MTS

0.533 ms

Outcome

medium dataset

Workload

Cassandra top-1 large throughput

Baseline

2,387.033 qps

MTS

3,975.467 qps

Outcome

clear win

Workload

Cassandra query-ready rate

Baseline

62.338 rows/s

MTS

587.516 rows/s

Outcome

>9.4x

Baseline means PostgreSQL + pgvector for pgvector tests and Apache Cassandra for Cassandra-compatible tests. Pgvector scope uses 1 PostgreSQL + pgvector node versus 1 MTS node plus 1 pgvector gateway; Cassandra-compatible scope uses 3 Apache Cassandra nodes versus 3 MTS nodes. Wins follow pre-agreed criteria and tolerance bands; baseline and candidate results were recorded separately, with non-scored diagnostics and setup reruns excluded.

What Developers Build

Real workflows without the multi-system tax.

MTS is built for practical application patterns: support, marketplaces, telemetry, financial workflows, and modernization paths where separate systems create stale data and operational debt.

AI-Native Support Platform

Combine case data, account documents, full-text search, vector retrieval, ACID assignment flows, SLA rollups, and analytics.

Marketplace Feed and Search

Serve ordered feeds, active-listing paths, document attributes, product text search, vector recommendations, and seller rollups.

IoT and Device Telemetry

Handle device-scoped time-series writes, latest-state reads, hot streams, exact metrics rollups, and recovery requirements.

Financial Workflow System

Protect transfers, ledger events, account feeds, fraud counters, reporting rollups, and precise historical restore boundaries.

Cassandra Modernization

Keep a familiar CQL entry path while moving beyond table-per-query modeling, narrow LWT, and external analytics pipelines.

Multi-System Stack Reduction

Reduce the need to stitch operational records, search, vector retrieval, Redis hot state, warehouses, CDC, and repair jobs.

Evaluation Questions

Strong thesis, explicit scope.

MTS is positioned as the replacement for the old operational stack, but each migration still needs a clear workload, supported access path, and evidence boundary.

Is MTS a Cassandra replacement?+

It is not a faster Cassandra clone. MTS keeps a Cassandra-compatible entry point for supported workloads, then adds native access paths, transactions, analytics, memory residency, recovery, and stronger diagnostics underneath.

Is it DynamoDB-compatible?+

MTS supports DynamoDB-style endpoint override patterns for supported item, query, batch, transaction, backup, and restore workflows. It is an application entry point, not a claim of full AWS service parity.

Does it support ACID transactions?+

Yes for supported explicit session transactions. MTS supports global ACID for multi-row and multi-tablet workflows with durable commit decisions and serializable validation.

What does zero-ETL analytics mean here?+

Operational data becomes analytically readable inside the MTS database lifecycle. Core analytics do not require a separate CDC export, warehouse copy, or job that owns correctness.

Does MTS replace Redis, search, vector, and warehouse systems?+

The thesis is to replace the default multi-system operational stack where those systems exist only to patch database gaps. Design partners should validate the specific workloads and native paths they need.

How does MTS avoid unsafe query expansion?+

Access paths are declared database objects. EXPLAIN and ADVISE show the plan, pushed predicates, bounded work, verification, and the DDL needed when a query is not safe yet.

What should design partners evaluate?+

Start with a real workflow where operational data, hot state, search, vectors, analytics, recovery, or correctness currently require multiple systems and custom synchronization.

Early Access

Evaluate MTS against a real workload.

Bring a workload where Postgres, Cassandra, DynamoDB, Redis, search, vectors, CDC, or a warehouse have become part of the correctness path. That is where MTS should be judged.

Request access